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(57) Abstract 

An apparatus and method for providing a medical protocol j paphic. user interface which graphically merges medical treatments is 
provided. The apparatus and method generates a plurality of graphic images representing a medical treatment plan. The graphic images arc 
presented in a chronological order based in real or virtual time slots and may be viewed in either a flow chart or a chan view format. The 
chart view format may be used by healthcare professionals to enter data. The graphical images include an order node, result node and flow 
node. The various nodes may be connected to form a healthcare plan assigned to a patient Two separate medical treatment plans may be 
combined with duplicate or conflicting orders removed. 
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AN APPARATUS AND METHOD FOR MERGING MEDICAL 

PROTOCOLS 


B ACKGRQUNP Of THE INVENTION 

Field of the Inventinn 

S The present invention relates to providing graphic medical healthcare plans (protocols), 

and in particular a graphic user interface, for developing, viewing and implementing medical 
healthcare plans. 

Dgscriptiftn Qf thg Related Art 

Typically, developing a healthcare plan for providing medical services to patients has 

10 been a manual exercise. Often, a physician will consuuct a medical healthcare plan, including 
when and how certain medical services should be provided to patients on written charts or 
verbally to medical care providers. Generic medical healthcare plans have been developed by 
clinicians and committees, with input from other appropriate members of an interdisciplinary 
care team. However, adapting a generic plan to a specific patient further requires valuable time 

IS and effort to coordinate and manage the task. In implementing a medical healthcare plan, a 
variety of individuals will be responsible for providing different types of care to the patient and 
possibly entering results from the care provided. 

As can be seen, a number of problems are associated with developing and implementing 
present-day healthcare plans. First, communication between those generating the healthcare 

20 plan and those implementing the healthcare plan may be ineffective. For example, often, a 
physician will write brief notes on a chart regarding padent treatment. These brief notes may be 
interpreted erroneously, leading to wasted time and cost, and possibly detrimental care provided 
to the patient. Also, a chronological list of various treatments or services is generally not 
completed before the healthcare plan is initiated. If a complete healthcare plan is developed 

25 before treatment is initiated, possible errors or duplication in u*eatment may be revealed, and 
thus avoided, in a particular healthcare plan. 

Second, once a healthcare plan is developed for a particular patient under a certain set of 
circumstances, often it is difficult to retain or duplicate that plan for likewise patients with 
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similar circumstances. Thus, valuable time may be wasted in developing an identical or similar 

plan. Moreover, if a healthcare plan requires a slight modification, an entire medical healthcare 

plan must be developed including the slight modification instead of revising an existing 

healthcare plan. 

S In addition, when a healthcare planner orders a particular treatment, such as a laboratory 

test, there may be different test results which may require alternate further treatment. With 
present medical healthcare plans, it is difficult to construct a healthcare plan based upon various 
results from a specific treatment. A healthcare treatment plan may also include multiple 
healthcare treatments, such as multiple laboratory tests, further complicating a healthcare plan. 

10 Fourth, obtaining costs in typical medical healthcare plans is difficult. As described 

above, there may be alternate treatments, depending upon different laboratory test results; thus, 
projecting costs for a particular health treaunent plan must take into account multiple types of 
potential treatments based on different results from various treatment procedures. Without 
knowing specific costs associated with each step in the medical healthcare plan, it is difficult for 

IS hospital administrators to manage costs and allocate limited resources. 

Fifth, often a patient may require multiple healthcare plans that must be reconciled or 
merged into one plan. For example, if a patient is admitted to a hospital for a hip replacement 
and subsequently is diagnosed as having an infection, two separate healthcare plans must be 
implemented. These two plans can be carried out in parallel or merged in one to be carried out 

20 as one plan. In either case, a healthcare plan for the hip replacement must be reconciled with the 
healthcare plan for the infection. The timing and types of treatment, including drug dosages, 
must be reconciled in order to provide treatment for both conditions. 

Finally, once a successful medical health treatment plan is developed, reusing that plan, 
or transferring that plan to other healthcare providers, is limited. For example, a leading 

25 cardiologist who develops a healthcare plan for a new surgical procedure may not be able to 
readily transfer the healthcare plan to other cardiologists to be adapted and used in their 
practices. Thus, valuable time 

and effort would be saved in developing a single successful medical healthcare treatment plan 
and transferring it to other healthcare providers. 
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Therefore, it is desirable to provide an apparatus and method for providing a medical 
healthcare plan which will 1) reduce errors associated with communications between healthcare 
planners and providers; 2) allow for convenient modification of medical health ueatment plans; 
3) provide costs associated with each step in the medical health treatment plan, as well as the 
5 total cost of die medical health treatment plan; 4) reconcile two or more healdicaie plans; and 5) 
copy and transfer medical treatment plans to various medical healthcare providers. 

SUMMARY QF THE INVENTION 
Other aspects and advantages of the present invention can be seen upon review of the 
figures, the detailed description, and the claims which follow. 

10 According to the present invention, a data processing apparatus is provided. The data 

processing apparatus comprises a display for displaying data and input means for inputting 
data. A storage location is coupled to the display and the input means. Processing means 
controls the storage means, input means and the display means in response to stored programs 
arid input data. The display includes a plurality of graphic icon images, stored in the storage 

IS location, arranged on the display representing a medical treatment plan. A program merges a 
first set of graphic icon images with a second set of graphic images to obtain a combined 
treatment plan. 

According to an aspect of the present invention, the first set of icon images are arranged 
in a chronological order and a first icon image represents the medical order. The icon images 
20 may be assigned to a patient. Further, the first set of icon images and the second set of icon 
images may be arranged in a combined chart view. 

According to another aspect of the present invention, the first set of graphic icon images 
includes at least one order triplet having an order node, result node and flow control node. 

According to yet another aspect of the present invention, a method for displaying a 
25 graphic representation of a medical treatment plan is provided. The method comprises the steps 
of providing a first and second set of icon images representing a first and second medical 
treatment The first set of icon images are combined with the second set of icon images to 
obtain a third set of icon images representing a merged medical treatment, including the first 


3 

3IIBSininESIIEET(Ryi£ll) 


wo ^/15a21 PCT/US96/1 6833 

and second medical treatments. 

According to another aspect of the present invention, the method step for providing a 
first set of icon images further includes the step of arranging the first set of icon images in 
corresponding time slots with the second set of icon images. 
5 According to still another aspect of the present invention, the method step for providing 

a first set of graphic icon images includes a step for providing a order triplet. The order triplet 
includes an order node, result node and Flow Chart node. 

According to another aspect of the present invention, the method further includes the 
step of providing a first order icon image having a corresponding order description and 
10 providing a second order icon image having a corresponding order description. 

According to another aspect of the present invention, the method step of combining 
further includes the step of combining the first order description with the second order 
description. 

According to another aspect of the present invention, an article of manufacture, 
IS including a computer readable medium having a computer readable program means for 
displaying a medical treatment plan is provided. The computer readable program code means in 
the article of manufacture comprises a computer readable program code means for causing a 
computer to generate an image on a display representing a medical treatment. The article of 
manufacture further includes computer readable program code means for causing a computer to 
20 generate a first and second image representing a first and second medical treatment, 
respectively, on a display. Computer readable program code means are also provided for 
combining the first and second image to display a combined medical treatment plan. The first 
image includes an order triplet, including an order node, a result node and a flow control node. 
According to another aspect of the present invention, the article of manufacture further 
25 includes a computer readable program code means for causing a computer to generate a chart 
view of the first and second images. 

According to still another aspect of the present invention, the article of manufacture 
further includes computer readable program code means for causing a computer to generate the 
merging medical treatment image in time slots on a display corresponding to the first and second 
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medical treatment image. The first medical treatment image is the master treatment image, while 
the second medical treatment image is the merging treatment image. 


According to another aspect of the present invention, the article of manufacture further 
includes computer readable program means for causing a computer to compare a first order 
5 node image to a second order node image. 

BRTEF DRSCRIPTION OF THE PR AWING5; 
Fig. 1 illustrates an example of a Template Builder window with an open template 
according to the present invention. 

Fig. 2 illustrates an example of a Cost view according to the present invention. 
10 Fig. 3 iUustrates an example of Patient Charting view according to the present invention. 

Fig. 4 illustrates an example of a Plan Assignment window according to the present 
invention. 

Fig. S illustrates an example of an Export window according to the present invention. 
Hg. 6 illustrates the clinical template according to the present invention. 
IS Fig. 7 illustrates the main directory according to the present invention. 

Fig. 8 illustrates the Template Builder window according to the present invention. 
Fig. 9 illustrates the Template with a Start node and an Order Triplet according to the 
present invention. 

Fig. 10 illustrates separating the Order node from its associated nodes according to the 
20 present invention. 

Fig. 1 1 illustrates the Order Node Detail dialog box according to the present invention. 

Rg. 12 illustrates the Add Orders dialog box according to the present invention. 

Fig. 13 illustrates the Ckder Node detail box according to the present invention. 

Hg. 14 illustrates the Result Node detail dialog box according to the present invention. 
25 Hg. IS illustrates the Results Form dialog box according to the present invention. 

Fig. 16 illustrates adding the virus triplet according to the present invention. 


S 

suBsnrniESEEronuM) 


wo 97/15021 PCT/US96/16833 

Fig. 17 illustrates adding the strep triplet according to the present invention. 

Fig. 18 illustrates adding an Exit node according to the present invention. 

Fig. 19 illustrates the connections between the nodes according to the present invention. 

Figs. 19a-c illustrate various types of connections according to the present invention. 

Hg. 20 illustrates the Flow Control Node dialog box according to the present invention. 

Fig. 21 illustrates how to add the rule using the Rule Editor dialog box accordmg to the 
present invention. 

Fig. 22 illustrates a completed rule according to the present invention. 

Fig. 22a illustrates an Ongoing order according to the present invention. 

Fig. 22b illustrates an Ongoing order rule editor according to the present invention. 

Fig. 23 illustrates a template containing Plan nodes according to the present invention. 

Fig. 24 illustrates a Plan Node Detail dialog box according to the present invention. 

Figs. 25a-b illustrate a logic flow diagram of building a template according to the 
present invention. 

Fig. 2Sc illustrates a logic flow diagram of determining cost according to the present 
inventioa 

Fig. 26 illustrates the standard server object interface according to the present invention. 
Rg. 27 illustrates the server object relationship according to the present invention. 
Fig. 28 illustrates the creation of instances on different host machines according to the 
present invention. 

Fig. 29 illustrates an example library hierarchy according to the present invention. 
Fig. 30 illustrates a system libraiy interface according to the present invention. 
Fig. 31 illustrates the Plan Assignment dialog box according to the present invention. 
Fig. 32 illustrates how to open a patient's plan according to the present invention. 
Fig. 33 illustrates patient charting in Flow Chart view according to the present 
invention. 

Fig. 34 illustrates a Result Node Detail dialog box according to the present invention. 
Fig. 35 illustrates the Order Result Entry Form according to the present invention. 
Fig. 36 illustrates a completed order status according to the present invention. 
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Figs. 37-39 illustrates a patient chart according to the present invention. 
Fig. 40 illustrates a logic flow diagram of a Flow Chart and Chart view according to the 
present invention. 

Fig. 41 illustrates the plan elements exported from the "clinic.pln" and imported into an 
5 Excel spreadsheet according to the present invention. 

Fig. 42-42a illustrates the Plan Assignment dialog box according to the present 
invention. 

Fig. 43 illustrates a Flow Chart view of two templates according to the present 
invention. 

10 Hgs. 44-46 illustrate a merging of two templates according to the present invention. 

Hg. 47 illustrates a logic flow diagram of merging two templates according to the 
present invention. 

Figs. 48a-e illustrate a logic view of merging one time slot of two template nodes 
according to the present invention. 

15 

PETAILEP PESCRIFnON Of THE yNVENTKQN 

I. OVERVIEW 

A. Software and Hardware Environment 

The term "template" is used to refer to a generic healthcare treatment plan, protocol, or 
20 guideline. After a template has been assigned to a general patient or client, the template is 
referred to as "plan". 

The software or computer readable program code, according to one embodiment, used 
in developing, displaying and implementing templates and healthcare treatment plans, is named 
the Araxsys™ Solution. In a preferred embodiment, the Araxsys*^ Solution software is stored 
25 on a computer readable medium. 

The Araxsys™ Solution program is written in C+-f language and is stored on a 
computer readable disk. In the preferred embodiment, the Araxsys^^ Solution software 
program would be used in conjunction with a computer system having the following 
requirements. The computer is an International Business Machine ("IBM") compatible 
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computer having a 386, 486 or Pendum processor. The operating system would be either a 
Microsoft Windows 3.1. Windows for 3.11, Windows 95 or Windows NT operating system. 
The minimum random access memory ("RAM") would be 8 megabytes ("MB") and preferably 
16 MB, For relatively small RAM systems, virtual memory must be set as high as possible. In 

S an embodiment, virtual memory must be set to a minimum of 12 MB. In the preferred 
embodiment, the Araxsys™ Solution program would operate in conjunction with Microsoft 
foundation class ("MFC") software files and with WIN 32s software files in a 16-bit 
environment. Available hard disk drive space should include 2 to 7 megabytes depending on 
the size of the data and whether or not MFC or WIN 32s system files are being used. The 

10 monitor would preferably be a video graphic adapter ("VGA") or super video graphic adapter 
rSVGA") color monitor. 

In the preferred embodiment, the computer system would have an input/output device, 
such as a mouse, for "clicking" graphic elements. Clicking graphic elements refers to 
positioning a cursor on a display, which is conU-oUable by the mouse, on or near a graphic 

IS element and pushing a mouse button. 

B. Graphic User Jnt^f ace Overview 

Figs. 1-5 illustrate a general overview of display windows and features used in the 
present graphic user interface according to the present invention. 

Fig. 1 illustrates an example of a Template Builder window with an open template. The 

20 template graphically represents a medical healthcare tteaunent plan in upper window 10. The 
upper window 10 shows a Flow Chart view 1 1 of a medical healthcare treatment plan. The 
template contains a number of graphic elements including: a start node, three triplets of an order 
node, a result node, a flow control node and an exit node. These graphical elements are 
positioned in window 10 in order to represent a medical healthcare treatment plan. The 

25 graphical elements can be positioned in time slots, as seen in Fig. 3, which will be discussed in 
detail below. 

In Flow Chart view 1 1, the process flow begins with a Stan node, enters into the first 
Order nodes, and flows out to Result nodes. After the results are entered, the process flow 
continues on to a Flow Control node where the next step in the treatment is determined. As 
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described below, there are thiee types of process flows. 

The bottom viewing window 20 contains two different views of the template, each on 
separate tabs: Zoom view 21 and Cost view 22. A user flips between these views by clicking 
the corresponding tab. A user can also choose Zoom view and Cost view options from a View 
5 menu to show a specific template view. 

The Zoom view is used to see the details inside the nodes of the template. Each node is 
magnified or expanded to show information contained within, as well as the relationships 
between the nodes in the flow chart A user can use this view to examine the entire template. 

Fig. 2 illustrates an example of a Cost view 22. The Cost view 22 illustrates the cost 
10 associated with a medical healthcare template. The Cost view helps a user analyze the cost of 
treatment specified by a template. Cost view 22 also shows every possible path through the 
template and lists the cost of each path. Each row in the table of cost view 22 represents a 
single path through the template. The left most cell of each row contains the cost of that entire 
path. The remaining columns in the row represent the order nodes in the path. Each order node 
IS is Usted with its associated cost and the current accumulated cost. 

Fig. 3 illustrates an example of Chart view 30. Each step is represented by two 
columns. The first column represents order items in the node and the second column represents 
results status of the order. In each order node, there may be multiple order items or multiple 
instructions or directions in treatment. Therefore, there are multiple rows per column. An 
20 order item may also include healthcare business orders, such as verifying the insurance of a 
padent In this view, healthcare providers are able to input data at various stages of a healthcare 
template or plan using the results columns. In addition, healthcare planners and providers can 
see which treatment steps have been completed by review of the color of the columns - grey as 
completed, white as active. The Charting view 30 is used to input data and track patient 
25 progress view according to the patient plan. Flow Chart view 31 corresponds to the patient 
chart view. In Bow Chart view 31, it is the same window in which a user builds templates, 
except the flow is now "active." In other words, a user can start the flow, enter order result 
into the various nodes, and move through the flow as the treatment progresses using the Row 
Chart view instead of the Chart view if a user desires. Color-coding on the nodes show which 
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ones are completed and which are in progress. 

Fig. 4 illustrates an example of a Plan Assignment window 40. In this window, a 
completed template can be assigned lo a patient. This step merges a template with a patient's 
plan and enables a care provider to carry out the patient's healthcare plan, which may include 
5 various templates. Fig 4 illustrates the templates assigned to the patient "John Sanders." 

Rg. 5 illustrates an example of an Export window 5 1. The present invention allows for 
patient plans to be converted into generic templates or exported to other software tools for 
analysis. A user can export patients* plans in a specific format, or American Standard Code for 
Inforaiation Interchange (** ASCII"). 

10 11. BUILDING TEMPLATES 

A. Creatinp a Me dical Treatment Template 

Before a user can create a template, treatment work flow must be defined; that is, the 
order in which ureatment activities arc carried out for a given condition. 

A template is constructed from graphic elements or building blocks called **nodes." 
15 There are five kinds of nodes: Start, Order, Results, Flow Control, and Exit. Every template 
has a Start node, which indicates the start of the template. Likewise, every template has at least 
one Exit node, which indicates the end of the template. Between the Start and Exit nodes arc a 
series of Order, Results, and Flow Control nodes. 

Order nodes contain generalized orders placed during the course of a treatment. The 
20 Order node defines a list of generalized orders or healthcare treatment related activities "order 
items** that arc carried out at a given step in the template. Order descriptions may be placed into 
Order nodes from a library. Each order is described using attiibutes that include category, 
subcategory, name, description, cost, and duration. 

The Result node shows die status of the orders in the corresponding Order node. 
25 During patient charting, order results arc entered to the Result node. Result nodes contain order 
status (i.e., an order was done or not done) and result values (i.e„ electrolyte measurements). 

Flow Control nodes contain rules Uiat govern the branching among nodes in Uie 
template. The Flow ConU-ol node contains rules tiiat select a branch at a decision point in a 
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template or plan, and estimates of the likelihood of branching down given paths. During patient 
charting, the Flow Control node suggests the next step to the healthcare provider based on the 
rules and the results entered in Result nodes. A typical rule in a Flow Control node looks like 
this: 

5 If(Rel:CBC:Hct:Val<=25)GOTO Transfusion at 5% 

When building a template, nodes are positioned in the chronological order in which they 
are to be carried out or executed. A user defmes each node and connects the nodes. 

Template creation involves the following activities: (1) placing Order, Results, and 
Flow Control nodes in their proper sequence; (2) filling in the orders (i.e., treatment 
10 procedures, medicine, and advice); (3) placing an Exit node at the end of the template; (4) 
deciding on the 

circumstances and order in which each template step is executed during treatment; and (5) 
saving the template. 

Thus, when a physician prescribes treatment for a condition addressed in an existing 
IS template, a stored treatment template can be used instead of creating a new one. If a treatment 
template does not exist for a given condition, a physician may retrieve a template from the 
library that addresses a similar condition, modify the template as needed, and start the patient 
treatment using the modified template. 

B. Clinical Template Example 
20 In this example, a simple template called the Clinic Template 60, as shown in Hg. 6, is 

built to u^at a patient complaining of a sore throat. Fig. 6 illustrates graphically a medical 
healthcare template to treat a sore throat condition in a Flow Chart view. A simplified work 
flow for a sore throat condition can be represented below: 

On the first visit with the patient, a healthcare provider gathers routine vital statistics 
25 (i.e., temperature, weight, etc.) and takes a throat culture. A strep test is ordered from the lab. 
If the result of the strep test is negative, go to the second step and treat the patient assuming the 
sore throat is from a virus. If the result of the step test is positive, go to third step and treat the 
patient for strep throat 


11 

smsmuiESBEEroiniEii) 


wo 97/15021 PCT/US96/16833 

If the strep test was negative, give the patient self treatment instructions for a viral 

infection. Exit the work flow. 

If the strep test was positive, give the patient a prescription for penicillin and self 

treatment instructions for strep throat. Exit the woik flow. 
5 1. rreatinp a New Template 

Using the sore throat work flow protocol above, a healthcare planner can develop the 

Clinic Template 60, a generic treatment template for a patient who has a sore throat The 

template may be used by any physician or healthcare provider when determining whether a sore 

throat is due to a virus or strep. 
10 Building a Clinical Template 60, as shown in Fig. 8, is initiated by clicking the Build 

Templates button 70 on the Main Director 71, as shown in Fig. 7. The Araxsys™ Solution 

Main v^ndow 85 appears in Template Builder mode as illustrated in Fig. 8. In this mode a user 

builds, reviews and modifies generic health templates. In an embodiment, a new template 

automatically contains a Start node 80. 
IS . A toolbox 81 is located on the right hand border of window 85. Toolbox 81 contains 

five tools, each represented by an icon, that aid in building templates. The five tools are 

Selection 81a, Generalized Order Triplet 81b, Plan Node 81c, Exit Node 81d and Connection 

81c. 

The Template window is divided into columns by dotted, vertical lines 82. These lines 
20 divide the template into time intervals that advance in time from left to right. Headings at the top 
of each column label each time slot. By default, the time slots are labeled by "day/shift," but 
there are a variety of other time slot labels that may be selected. The width of the time slots is 
also adjustable. 

2. Placing Order. Results, and Row Control N ft d g S 

25 (Tripteu?) 

Fig. 9 illustrates adding an Order node Orl, Result node Rel and Flow Control node 
Fll to a template. The Order node Orl contains the physician s orders, such as lab tests, 
nursing procedures, x-rays, prescriptions, and other kinds of treatments or actions. These 
generalized orders may be taken from a library and placed in Order node Orl. The Order node 
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Orl groups all of the orders for a given step in the template. 

An Order triplet is entered by clicking the Order tool 81b in toolbox 81. The cursor 
turns into the icon shape. By moving the cursor to the right of the Start node and clicking once, 
an Order triplet is placed into the template. A series of three nodes appears. Every Order node 
S Orl automatically has one Result node Rel and one Flow Control node Fll attached to it; 
therefore, whenever a user places an Order node from the toolbox, a triplet is actually selected 
and positioned. 

In an embodiment, order node Orl may be separated from Result node Rel by clicking 
and dragging the Result node Rel to the right to set it off from Order node Orl, as shown in 
10 Fig. 10. Another embodiment allows a user to choose the time scale setting from the Options 
menu 86 and increase the size of the number of units per slot unit from 5 to 7. This will 
increase the space between the time slot separators (the dotted lines 82). The chronological 
order of a template may 

be either in real time or virtual time. Real time is the current active time of a triplet or plan and 
IS active virtual time is a time set by the user. 

3. Naming a Node 

To make it easier to follow the template^ a user may assign a name to each node in place 
of its default. For example, the default name for the first Order node Orl is ''Orr, but that 
doesn't tell a user much about the procedures within that node. Since the first step in the Clinic 
20 Template determines whether or not the patient has Strep throat, a user may assign the name 
"Str^?" to Order node Orl by: 

a. Click Order node Orl to select it. 

b. Choose Name from the Edit button 1 19. 

c. In the Order Node Detail dialog box, type Strep? in Name field. 
25 d. Click OK button 113. 

The word "Strep?" now appears under Order node Orl. Next, a user may place orders 
in the Order node. 

4. Placing an Qrfgr 
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Fig. 11 illustrates the Order Node Detail dialog box 110 according to the present 
invention. 

By double-clicking Order node Orl in the triplet shown in Fig. 9 or 10. The Order Node 
Detail dialog box 110 appears showing the list of orders (i.e., content) in Order node Orl. 
5 There are no orders shown in Fig. 1 1 in the Order node. 

The top of this dialog box 1 10 contains two "tabs"; Atmbutes 1 1 1 and Content 1 12. 

The following lower bunons have the associated action: 

OK button 113 saves changes made in this dialog box when clicking. 

Cancel button 1 14 closes dialog box 1 10 without taking any action when clicking. 
10 Apply button 115 currently remains disabled. 

Help button 1 16 displays Help for dialog box 1 10 when clicking. 

The upper buttons at the top give a user four choices: 

Add button 1 17 adds an order to be carried out when this template is executed when 
clicking. 

15 . Replace button 1 18 replaces the selected order with another woric order when clicking. 

Edit button 1 19 edits the detail of the selected order, including the order's result values 
when clicking. 

Delete button 120 deletes the selected order when clicking. 

Fig. 12 Illustrates the Add Orders dialog box 122 when clicking add button 1 17, shown 
20 in Fig. 1 1. according to the present invention. 

All the orders stored in the library appear in the Command List area 121. The work 
orders in the library are organized by category and department and are displayed as file folders. 
The Library folder contains category folders, which in turn contain folders identifying the 
departments that typically carry out the orders. Each department folder contains a series of 
25 work orders for the selected category and department. 

In the first step of the Clinic Template, two work orders are specified: a strep throat 
culture, and the routine nursing vital statistics. These work orders are added to the Order node 
Orl by the following steps: 

a. Use the up/down arrow keys 129 to scroll through the list, and double-click the 
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Labs folder in the Command list to open it 

b. Double-click the Bacteriology folder, and then click Strep ($40.00) to pick the 
strep test. This work order appears in the Work Order area 125 at the top of this 
dialog box. 

c. Click the Place Order button 123 to add the order to the list of orders in the 
Orders dialog box. 

d. Scroll to the bottom of the Command List, and then double-click on the Vitals 
folder. 

e. Double-click Nursing, and then click Routine ($20.00) as the order to be 
performed. 

f . Click Place Order button 1 23. 

g. Click Done button 124. The Add Orders dialog box 123 goes away. Both of 
the work orders the user placed are listed in the Orders dialog box 1 10 as shown 
in Fig. 13. If the user accidentally placed the same order more than once or 
placed the wrong order, select the order and click Delete button 120 to remove it. 

h. Verify that all of the work orders you selected are listed correctly, and using the 
buttons across the bottom of the screen, click OK button 113. The Order Node 
Detail box 110 goes away and a user can see die template. 

Thus the contents of the strep? Node shown in Fig. 6 is filled according to the present 
invention. The number 2 above the strep? node shown in Fig. 6 indicates the number of orders 
it contains. For every work order, there is a corresponding order result in the Result node Re. 
Since two work orders have been selected, there are two results in Result node Re. 

Next, a user may view the contents of the Result node. 

S. Viewing the Result Nftdc Contgni 

The Result Node dialog box 140, as illustrated by Fig. 14, lists the status of orders 
placed in corresponding Order nodes. Completed work orders show a "Done** status and 
incomplete work orders show a "Not Done" status. Orders may also show an "Exception" 
status if the order cannot be filled as expected. 

Fig. 14 illustrates the Result Node Detail dialog box 140 according to the present 
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invention. Double-clicking Result node Rel presents Result Node detail box 140. Clicking 
content tab 142 displays the content page. All of the orders show a "Not Done" status on the 
content page because a user is still in the Template Builder mode. 

Double clicking the Vitals order 143 in the list of orders* Result Form 150 is displayed, 
S as shown in Fig. 15. This form is where a care provider enters the results of the vitals order 
when the template is being charted as part of a patient's plan. 

When charting a patient, healthcare providers enter results of the vital statistics and set 
the status to "Done" in Result Form 150. This will mark the entire order as "Done" in the 
Result Node Detail dialog window 140. 
10 Clicking Cancel button 151 closes the Results Form dialog box 150 and clicking OK 

button 144 closes the Result Node Detail dialog box 140. 

Next, a decision based on the results of the lab work requested in the first Order node 
Orl must be made. As for the lab results, there are only two possibilities: either the sore throat 
is due to a virus or ii*s due to strep bacteria. So, a user needs to add two more Order nodes: 
15 one^to hold the work orders if the strep test is negative, and another to hold orders if the strep 
test is positive. 

6. Addiny Mote Order Nodes 
To handle these two possibilities, a user adds two more Order triplets, one triplet for 
each possible branch in the u^atment course. A user may name the first uiplet "Virus" and the 
20 second one "Strep." The Virus node will describe what to do if the patient has a sore throat due 
to a virus. The Strep node will describe what to do if the patient has strep throat 

Clicking the Order node tool 81c and dragging it to the right of the Fll node, and click 
once positions the Order triplet 

Initially, the Orl appears beneath the Order node. By default, each uiplet a user creates 
25 is numbered in consecutive order, starting with the number 1. Since the first Order node Orl is 
renamed Strep?, the new Order node is numbered 1 by default. However, since the furst Result 
and Flow Control node are still numbered U the second set of Result and Flow Control nodes 
are 

assigned the number 2. Order node Orl may be renamed before assigning work orders to the 
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new Order node. 

Orl node is selected by clicking it 

Name is chosen from an Edit menu or double click Orl node to show the Order Node 
DetaU dialog box 1 10 and click the Attribute tab 11 1 as above. 

In the Node Attribute dialog box that appears, type Virus in the Name box and click OK 
button 113, The word "Virus" now appears in place of Or 1 . The Result node must be dragged 
over a bit to separate it from the Order node, as shown in Fig, 16. 

An additional triplet may be added by the above steps. However, this time, the triplet 
would be positioned below the Virus triplet and the new Order node would be named "Strep", 
as shown in Fig. 17. 

Work orders to the Virus and Strep Order nodes then must be assigned. One work 
order will be assigned to the Virus node and two work orders to the Strep node. 
7. Assipninp Work Orders to Nodes 
To assign work orders for the Virus node: 

a. Double-click the Virus node. 

b. Click Add button 1 17 in the Orders node detail dialog box 1 10. Patients with 

sore throats caused by a virus are to be discharged with a discharge direction 
sheet 

c. Double-click the DCPlan folder in the Command list in add orders dialog box 
122 shown in Fig. 12. Discharge direction sheets are grouped by department. 

d . Double-click the Clinic folder, and then double-click DC.Instnictions_for.Virus 
($0.00) to select the work to be performed. 

e. Click Place Order button 127 to add the order to the list in the Orders dialog box. 

f . Click Done button 124. The Add Orders dialog box 122 goes away. 

g. Verify that only the work order the user selected is listed, and then click OK 
button 1 13. The Orders dialog box 1 10 goes away, 

A "1" appears above this second triplet, as shown in Fig. 18, indicating one work order 
is assigned. 

To assign work orders for the Strep node: 
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a. Double-click the Stiep node. 

b. Click Add button 1 17 in the Orders dialog box 1 10. Patients with sore throats 
caused by the strep bacteria are treated with two work orders: DCPlan Clinic 
and a ten-day dose of penicillin. 

c. Double-click the DCPlan folder in the Command Ust in Add Orders dialog box 
122 to open it 

d. Double-click the Clinic folder, and then double-click 
DC_Instructions_for_Bacteria ($0.00) to select this work order. 

e. Click Place Order button 127 to add the order to the list in the Orders dialog box. 

f . Double-click the Meds folder in the library list 

g. Double-click the Pharmacy folder, and then double-click 
PO_PenicillinJ$ 10.00) to select this drug. 

h. Click Place Order button 127 to prescribe the drug and add it to the list in the 
Order node detail dialog box 1 10. 

i. Click Done button 124. 

j. Verify that only the work orders you selected are listed, and then click OK 
button 113. 

A "2" appears above this triplet, as shown in Fig. 18, indicating two work orders are 
assigned. A template containing a Start node and three triplets having orders, treatment results, 
and flow control has been developed. The last node to add to the template is the Exit node Ex 1 . 
The Exit node simply marks the end of the template, like the Start node. 

8. AdHinpanExit Node 

An Exit node Exl is positioned by clicking the Exit node toolbox 81c. selecting and 
placing it to the right of the other nodes» as shown in Fig. 18. 

Now that nodes are in place, connections between them must be made. A connection 
tool 81e in toolbox 81 is used to specify the flow between the different sets of orders. 

9. ronnecting the Nodes in the Temolatc 

The Flow Control node contains the rules that determine which set of orders are 
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followed. Row Controlnodes are connected to one or more Order nodes. However, only one 
of the Order nodes will be executed. 

First, the Start node is linked to the Strep? node. This connection indicates the node to 
execute first. The first Flow Control node Fll is linked to both the Virus and Strep Order 
nodes. Doing so indicates that a decision will be made based on the results of an order filled in 
the first Order node. 

a. Click the Connection node tool 8 le in tool- box 8 1 to select it. The pointer turns 
into a large arrow pointing up. 

b. Click once on the Start node, and then once on the Strep? node. An arrow 
appears between the two, indicating the order of the work flow. The 
Connection tool remains selected until a user selects another tool So, a user can 
go ahead and make the other connections. 

c. Click the Fll node and dien click the Virus node. 

d. Click the Fll node and then click the Strep node. 

e. Click the F12 node and then click the Exit node. 

f . Click the F13 node and then click the Exit node. 

g. Unselect the Connection tool by either clicking the Connection tool again or by 
selecting any other tool. 

The template having the connections is shown in Fig. 19. 

After making these connections or links. Flow Control node Fll must be edited to 
include the rules that govern the branch taken during patient charting. 
10. Connections 

As seen above, connections indicate relationships.between nodes in a template. There 
are three types of connections: Order Results, Process Flow and Information Flow. Each type 
of connection is represented differently to help a user understand the relationship it represents, 
a. Order Results 

These connections are illustrated with double lines and indicate the relationship between 
orders and their corresponding results. Fig. 19a shows an order node with four lab test orders. 
One of the orders in not available until some time later. The Order Results connections show 
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which Result Nodes hold the results of the orders placed in a given Order node. 

Whenever a triplet is placed into a template, the Order Node is automatically given one 
of these connections to the Result node. As with all connections, when nodes are moved 
around the template, the coimections remain intact 

s b. Process Flow 

Process Flow connections are created using the Connection tool 81c from Toolbox 81 
described above. 

C. Information Flow 
These connections make order results from one triplet available to the rules in another 
10 triplet They arc illusuates in a template with a single line between a Resuk node in one triplet 
and a Flow Control node in another triplet, as seen in Fig. 19c. 

The connection is created using the Connection tool the same way Process Flow 
connections are created. A user creates these connections when a rule needs to reference the 
results of an order completed in a previous step in the plan. The example in Fig. 19c shows an 
15 Information Flow from the Result node in the "has.fever?" triplet to the How Control node in 

the •'Fever" uiplet 

11. Programming the. Flow Control Nodes 
A Row Conu-ol node may be connected to two or more Order nodes, but only one of 
those Order nodes will be executed. Each Flow Conu-ol node contains a set of rules that 
20 determine which Order nodes will be executed in the next step of the template. A user defines 
the rules by creating simple expressions that reference the results of completed orders or other 
variables available in the template. 

a. Double-click the flow control node Fll. The Flow Control Node dialog box 200 
appears, as shown in Fig. 20, listing two rules. Each branch in the template is 
25 associated with a rule. The rule indicates the Order node executed when the rule 

is satisfied and the branch is taken. 

The first rule in the list is the default rule. It is taken when all of the order 
results are available and no other rule is satisfied. In this example, the default 
branch leads to the Virus node. The orders in the Virus node are placed if the 
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second rule is not satisfied. If the second rule is satisfied, the orders in the Strep 
node are placed. 

b. Click the second rule (If () GOTO Strep...) in the Flow Control Node dialog 
box 200, to select the second rule. Since the rule for the Virus branch (the 

S default) is satisfied only if the rule for the Strep branch is not, the second rule is 

edited first This rule is edited using the Rule Editor dialog box 210 shown in 
Fig. 21. 

c. Click Edit Rule 201, as shown in Fig. 20. to edit the contents of the currently 
selected rule. In general, rules contain expressions that reference the results of 

10 orders. The file folder tree in the lower left corner of the Rule Editor dialog box 

210 contains all of the order result values that this Flow Control node can 
reference. The result of the expression must be a logic value, i.e., TRUE or 
FALSE (or positive and negative). 

d. Double-click the Rel folder in the Rule Editor dialog box 210. Then double- 
15 ^ click the Strep folder, the Test folder, and Value. A second rule has now been 

created. It appears in the scroll box 215 next to the word "IP. A user can read 
the files as follows: "If the result of the Strep test value is positive (meaning the 
result is positive) then follow the procedures in the Strep Order node." Since 
there are no other branches, a user can also read in the following: ''Otherwise, 

20 follow the procedures in the Virus Order node." 

Notice that Result node name, "Rel" in this case, is replaced with the keyword 
"THIS.- The keyword "THIS" indicates the rule references the results of an 
order in this triplet. A user can manually replace "THIS" with "Rel" if a user 
wants to limit the rule to reference only the results in a node named "Rel". If a 

25 user leaves it referencing "THIS", the rule can be copied into the library and 

used in another template without change. The result is the same during patient 
charting whether the reference is prefixed by "THIS" or "Rel." 
However, if a user wants the rule to reference results of an order from this node 
or a previous node in the patients plan, a user can replace the keyword "THIS" 


21 

syBsnn^ 


wo 97/15021 PCT/US96/16833 

by the keyword "LAST". A user can simply replace the text in the rule editor 
field, or select "THIS" in the rule editing field, click the "Positional..." button 
211 on the rule editor, and choose LAST from the list. If the order is not 
present in this triplet, a rule specifying "LAST" will reference the most recent 
5 order results. 

e. Next, the probability that the results of the Strep test will be positive must be set 
In general, the probability values are set based on experience, studies, or metrics 
gathered over time. For this example, click the At Probability drop-down arrow 
button 213 and select 10 as the percentage. 
10 f- Click Done button 212 in the Rule Editor dialog box 210, In the Flow Control 

Node Detail dialog box 221 shown in Fig. 22, notice that the first rule 
automatically changed based on the second rule. Since the probability that the 
Strep test will return a positive result is about 10%, the probability that the sore 
throat is due to a virus is 90%. 
15 . g. Click OK button 220 in the Flow Control Node E)etail dialog box 22 1 to close it. 

A user must have enough rules to cover all of the branches out of the Flow Control 
node. Because every Flow Control node contains a default rule and may contain additional 
rules, the nimiber of rules is always one less than the number of branches. Thus, if a node has 
four branches, it must also have three rules. In this example, a user only needs to enter one 
20 rule. 

Note that even though the default rule is created, a user can still set the default rule. 
However, because the definition of a default rule is that it will be used when no other rule 
applies, the rule put in the default rule will not be evaluated as criteria for using the rule as long 
as it is the default An option is available to change the rule to a non-default rule. At this point, 
25 the rule will be evaluated. 

12. Onpoinp Order 
Ongoing orders are orders which are repeated periodically, or run continuously, until 
certain criteria arc met Ongoing orders may be selected from Ongoing Order button 128 in Fig. 
12. An Ongoing Order Strep with result node R2 and Flow Control node D2 is illustrated in 
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Fig. 22a. Edit Order window, a special version of the Rule Editor window is displayed, as 

illustrated in Fig. 22b. The unique characteristic of this version of the Rule Editor, is the 

Repeat and Run buttons in the top left-hand comer. 

By clicldng the Repeat button the order is repeated according to the rules specified in 

5 this window. 

When the Repeat button is selected, the label above it reads "Repeat Until," and the field 
labeled "Next Starting" and "Number of* lets a user further define the repeating order. The 
field labeled "Next Starting** indicates the date to start the next repetition of the order. A date or 
work shift is entered in this field. The field labeled "Number of* indicates the maximum 
10 number of times the order is to be repeated. The option arrow next to the field is clicked to 
enter a multiple of five, or any number greater than zero may be typed. 

The Run button is clicked to indicate the order is to run continuously until the specified 
rules are met. When the Run button is selected, the label above the Repeat button reads '*Run 
Until," and the "Next Starting" and "Number of fields are replaced with the "With Medicine*' 
IS and "At Rate (ml/minute)" fields to help a user further define a continuously nmning order. The 
field labeled "With Medicine" indicates medication that is to be given in combination with a 
specified ueatmenL The field labeled "At Rate (ml/minule)" indicates the speed that the dose of 
the medicine should be administered. For example, a user can create an ongoing order 
specifying a base TV solution and indicate the specific medication added in the "With Medicine" 
20 field (e.g.. Potassium) and a flow rate of 1 ml/minute. 

A user specifies the conditions when the Ongoing order is to be discontinued in the 
scrollable field beside the Repeat and Rim buttons. The discontinuation conditions are specified 
as a logical expression. 

Some keys on the right hand side are gray. These keys are not applicable to this 
25 window. The rest of the keys are common to all the rule editors. 
13. The Plan Node 
The Plan node provides a way for users to create a template that branches into another 
template. The Plan Node acts as a special type of exit node because it causes the current 
template to exit and the new template to begin. 
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Fig. 23 illustrates a template containing Plan nodes according to the present invention. 
This is an example of a template that might be used by an emergency department screening 
nurse when a patient comes to the emergency department complaining of a sore throat. The first 
step in the template in Fig. 23 specifies an assessment of the patienfs throat, and any relevant 
5 history, to determine whether the patient should be treated for a bacterial or viral throat 
infection, or throat injury. Based on this decision, the patient is started on one of two 
templates. Before adding a Plan node to a template, first create the templates behind the Plan 
nodes. Since each Plan node is a complete template, a user will need to follow the procedure 
for cieating a template to establish the content within each Plan node. 
10 A user can insert a Plan node in the template as a place holder for the template before it 

is completed. A Plan node may be placed into the template using the Plan node icon in the 
toolbox with the other node types, for example, order triplets and the exit node. 

Assuming a user has already created a template for a Plan node, the following steps 
place the Plan node into a new template. 
15 ^ a. Click the Plan node icon in the toolbox, move the cursor to the desired position 
in the template and click the mouse to place the Plan node into the template. 

b. Select the empty Plan node and choose the Name option from the Edit menu. 
This brings up the Plan Node Detail dialog box 350 as shown in Fig. 24. 

c. If the template has been previously created and saved, double click the name of 
20 the desired from the list of available templates. This attaches the Plan node to an 

existing template. A user may enter a description and assign the Plan node to a 
department 

d. Click OK button 351 to close the dialog box. 

At this point, the Plan node is tied to another template. If you double-click on the Plan 
25 node, the template is brought up and you may edit it 
14. fSflvinp theTemnlate 
To save the template, the Save from the File menu may be chosen using the default 
name given by Araxsys™ Solution. Or the following can be done: 
a. Choose Save As from the File menu. 
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b. 


A Save As dialog box will pop up for a user to type the name of the template. 


Make sure the file is in the "data" subdirector in the director where icm.exe is 


located. 


c. 


Click OK. 


5 


C. 


Building a Template Flow Chart 


Figs. 2Sa-b illustrate the logic flow in building a template according to the present 
invention. Objects, methods and attributes described in Figs. 25a-b are described in detail 
below. A user first needs to decide the time slot scheme to be implemented in logic block 500. 
A time scale dialog box is then displayed, allowing the user to select the scale and unit in logic 

10 block SOI. The corresponding template object (for example, template object 350 in Fig. 27) is 
updated to reflect the new time scale and time slot size in logic block 502. Based upon the 
selected time slot scheme, the number of time slots are deiermined and labeled in logic block 
503. The window reflects the new selection. In logic block 504, a user selects the node icon in 
the toolbox and drops the icon next to the start node. A triplet is then drawn in logic block 505. 

15 In logic block 506, an instance of the node object is created. The node object is then added to 
the template object list (node.list 371 in H. 27). Further, the associated attributes of the node 
are created and a unique name may be determined for the node of triplets. If this is the last node 
before the Exit node, the logic flows to logic block 507. Otherwise, a user may select another 
node in logic block 504. A user connects the nodes in logic block 507. In logic block 508, a 

20 node is selected by the user to fill its contents. An Order node window will be displayed with 
the current order contents from the node object In the case of a new node, the display will be 
empty. In logic block 509, the library order item object (for example, order 358 in Fig. 30) is 
traversed to list all orders in the library in the order conieni window. In logic 510, a user 
selects the order items to be added to the node object. Further, attributes of the order are added. 

25 With each order, an entry in the result node object (Result node 359 in Fig. 27) is created and 
the status of the result item is linked to the control node which contains the rule (If Rule 353 in 
Fig. 27) object via the information flow link list. The name (Name 399 in Fig. 27) of the node 
may be changed in logic block 511. The uniqueness of the name is verified by comparing all 
the names in the node list of the triplet object before the change becomes effective in the object 
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and reflected on the screen. A flow control node is selected to create rules for branching in 
logic block 512. A search for the destination node in info_destinationJist which is connected 
to the flow control node is then carried out. The Flow Control node detail dialog box is then 
displayed. The flow control rules will be empty, except for the default rule. User will click the 
5 rule or the Edit Rule button to display the rule editor dialog box in logic block 513. The 
contents of the rule editor dialog box is constructed after all the result node objects connected to 
the flow control nodes are searched in the node Jisi of the triplet. The results which can be 
used to contribute to the rule is displayed in the rule editor in logic block 514. In logic 515, the 
user creates the rule and enters the percentages. The rule is then stored in the (Expr. 354 seen 
10 in Fig. 27) object and the percentages are then added to derive the percentage for the default 
rule. The percentages are then displayed on the screen. If no other nodes need to be filled, the 
exit node is selected and placed in the template in logic block 516. 
D. Cqs^ 

Fig. 25c illustrates the logic flow of determining the cost of various healthcare 
15 treatments according to the present invention. The cost of various treatments is initialized at the 
Start node in logic 600. A search for the next destination node, which has not yet computed 
cost, using the node list 371 and info.destination in Result node 359, as seen in Fig. 27, is 
done. A total cost is determined by adding all item costs of the order node in logic 602. Each 
order object has an attribute object which contains associated costs for each order item. A 
20 running cost (i.e., new accumulated cost) is determined in logic 603 by adding the selected 
node cost (including all order item costs) which is multiplied by the percentage associated with 
the path which leads to this node to the current accumulated cost A determination is then made 
whether this node is the last node of a path. That is, if there is any destination node of this 
node. If this node is the last node, the present order node object is retrieved in logic 604, so we 
25 can use the same logic to compute the cost of the next path of the present node. Otherwise, the 
flow control node is followed in logic block 605 in order to determine die cost of die next 
destination nodes. 

III. ASSIGNING A TEMPLATE TO A PATIENT 
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A template may be assigned to one or more patients. When a template is assigned to a 
patient, it becomes part of the patient's plan. The patient's plan is a collection of all of the 
templates that have been assigned and possibly tailored to the specific patient Once a template 
is assigned to a patient, the template may be modified or executed. 
To assign the Clinic template to a new padent: 

a. Click the Plan Administrator button on the toolbar 81 shown in Fig. 8. A 
template may be assigned to patients from the Go To menu or click the Assign 
Template to Patients button on the Main Directory as seen in Fig. 7. The Plan 
Assignment dialog box 230 appears and lists current patients and stored 
templates. Fig. 31 illustrates the Plan Assignment dialog box according to the 
present invention. 

b . Click the template name to select the template. 

c. Click the patient's name. 

d. Click Assign Template 231. 

e. To add a new patient, type the patient's name in the New Patient Name Field 
232, press the Tab key to advance to the next field 233, and type the patient's 
social security number. Then click Add New Patient button 235. The patient's 
name appears within the Patients list on the left as shown in Fig. 32. 

f . Click done button 234. The patient assignment is recorded and the patient 
assignment window closes. 

If a completed plan is under a patient's name, GUI asks if a user wants to archive die 
plan. If a user answers "yes," the plan is saved in the patient's archive directory for later 
review and the name of the archived plan is no longer listed in the existing patient tree. 


rV. PATENT CHARTING 

As described above, there are two different views available when delivering a patient's 
plan: Flow Chart view or Chart view. The Flow Chart view is ideal for simulating plan 
delivery in order to ensure the conecmess of a new template. The Chart view is more suited for 


27 

siiBsnnnESiiaroniEaD 


wo 97/15021 PCTAJS96/16833 
delivering care to a real patient and more closely resembles patient charts. 
A. Charting in th f-. Flow Than View 

A template assigned to a patient becomes part of the patient's plan and can be delivered. 
During the delivery operations, a user enters the results of tests and changes the stanis of orders 
when the order has been completed (i.e., filled). 

To deliver a patient's plan using the Flow Chart view: 

a. Choose Main Directory from the File menu to see the Main Directory window as 
seen in Fig. 7. 

b. Click the Assign Templates 71 to Patients button to see the Plan Assignment 
window. 

c. Double-click the patient's name in the patient list to see the templates that have 
been added to the patient's plan. 

d . Double-click the template name beneath the patient's name to see that template in 
the Flow Chart view. At this time, the Chart view exists, but is hidden. By 
dropping down the window splitter the Chart view is revealed. 

Fig. 32 illustrates how to open a patient's plan according to the present invention. 
Specifically, double-click myclinic.pln folder presents "Jim Sanders" Flow Chart view as 
shown in Fig. 33. In this view, colors are used to distinguish between plan steps that (1) 
have already been completed, (2) arc presently active, and (3) have not been completed. 

A user can change the colors using the Color Preference command from the Options 

menu. 

Nodes marked active contain orders that have been placed and are awaiting results. 
There may be more than one active node in the plan at one time, but the right most active node is 
where the next branching decision is made in the plan. 

Each time an order result is entered, the rules in the Flow Control node are evaluated to 
see if enough information is available to branch to the next step in the plan. When all of the 
order results specified in a rule are entered, the rule is evaluated. If the nile is satisfied, the rule 
will become active and take the plan down the corresponding path. 

e. Double-click the Rel node to display the Result Node Detail dialog box 260 in 


28 

SUKinVIESIIEETQiaEW 


wo 97/15021 PCT/US96/16833 

Fig. 34. It lists work orders and their completion status. At this time, none of 
the work orders have been completed and all are marked "Not Done." 

f . Double*click the first item in the Order Status dialog box. The Result Form 
dialog box 270, as illustrated in Fig. 35, appears. In this dialog box, a user 

5 enters values to indicate the results of tests and change the completion status of 

work orders. The test results are entered in the Value column. 

g. Click in the value colimin 272 of the Test row. Type FALSE or N for negative 
(the default value), or TRUE or P for positive. For this example, type P. 

h . Press enter or select another field. 

10 i. Click the down arrow 271 in the Status box and change the status from Active 

(not done) to Done. 

j. Click the Done button 273. The status has now been updated for this procedure, 
it is listed as Done in the Result Node Detail dialog box as shown in Fig. 36. 
The Vitals order remains Not Done. 
IS . k. Even though the Vitals order remains Not Done, Click OK 281 to close the 
dialog and view the plan flow chart. 
The GUI, according to die present invention, automatically detennines the next step in 
the care flow based on the results of the strep test even though the vitals were not completed. 
The Strep Flow Control node Fll in Fig. 23 is completed (shaded dark gray) and the Strep 
20 Flow Control node F13 in Fig. 33 is active (green). 

In this example, both the Rel and Re nodes are active (green) and awaiting result 
values. This is because the branching rule in the Flow Control node does not include any 
results from the vitals. If a user wants the branching logic to consider one or more of the vital 
statistic values (i.e., temperature to check for a fever), a user can modify the rule to reference 
25 the vital value(s). Even though the vitals are generally taken in advance (probably by a nurse 
even before the physician sees the patient and orders the strep test), and are normally available 
before the strep test results, this example demonstrates that the rules become active as soon as 
the results that they depend on are available. 

L Update the results of the Re3 orders in the same way you completed those for 
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Rel. 

At any time during charting, a user can open a Result node or Flow Chart Node to view 
its content after it has been completed. A user can also choose to chart from the View menu to 
see all the past activity in this plan at a glance. 
5 1. rhartinp Into a Plan Node 

When a user takes a branch down a path that leads to a Plan node in the patient's chart, 
the Plan node is highlighted in both the Row Chart and the patient Chart views as shown in 
Fig. 37. The Plan node indicates it is Not Done until you double-click on this step in the plan 
(either the Plan node in the Flow Chart view or the column entry in the patient Chart view). At 
10 this point, the Plan node is set to Done, indicating you have entered the Plan node. 

When a user charts a patient plan into a Plan node, the previous plan is discontinued and 
the new plan is started. The view of the new plan will be used to continue charting. Whenever 
a user leaves a plan, the user is presented with a dialog box that asks if a user would like to 
archive the plan. It is generally a good idea to not archive the old plan when entering a Plan 
IS node. 

2. ManlW^lyEx6CTrtingaPlan 
There are two ways to manually direct the execution of the plan: force the plan to 
branch, and reexecute a step in the plan. 

To force the plan to branch down a specific path, regardless of the result values and the 
20 flow control rules, a user opens the right-most active Flow Control node, select the rule 
governing the desired path, and click the Execute button. The plan will branch down the 
specified path. 

To reexecute a step in the plan, for example, if treatment has gone down one path and a 
user needs to back up the plan to go down another path, a user reexecutes the previous plan 
25 step. Click the order node to go bade to and either click the Execute button on the tool bar 81 or 
choose Execute option from the View menu. The plan will back up to the selected node making 
it the right-most active node. 

B. ChRTtinf in the Patient Chart View 

Charting a patient using the Chart view is very much the same as charting in the Row 
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Chart view. 

a. On the Main Directory seen in Fig. 7, click Chart Patients button 72. A user 
may also choose Go To Chan Patients menu on the tool bar 8 1. 

A summary of all the patients is displayed. This example shows one patient and one 
S plan (the clinic plan that treats strep throat). 

b. Click a patient's name to display the patient's chart. When entering the patient 
chart, the Flow Chart view is usually hidden. While the Chart view is displayed, the window 
splitter can be used to reveal both views. 

In the Chart view as shown in Fig. 38« each step in the patient's plan is represented as a 
10 pair of columns. The content of the Order node is shown in the first column. The 
corresponding order status is shown in the second column. Each step is labeled at the top with 
the step name and the time slot encompassing the step (in the example, time slots have been 
disabled so the step name is blank). The columns proceed from left to right by time slot 

The column with white cells 301 or 302 represents the active step and is ready to be 
15 charted. The gray columns to the right of the active column show the most probable path 
through the plan. The probability values associated with each rule determine the most probable 
path through the plan. In this example, the Virus path is the most probable. 

c. Double-cUck the white cell 301 to the right of the Strep order to see the Results 
Form dialog box. Enter the results of the strep test (P for positive) and click the 

20 Done button to mark the work order "Done" as in charting in the Flow Chart 

view example above. The effect is the same; the plan branches down the Strep 
path. Also, as in the Flow Chart example, the Vitals results (Rel) are left active 
(since they have not yet been entered) and the results of the strep orders become 
active as shown in Fig. 39. 
25 d . Enter the required results for the Strep orders to complete the plan. 

To see the Flow Control node content on the chart, choose Show Chart Details from the 
Options menu to show the rules. An active rule will contain Bold characters. When a user 
closes the chart or switches to a different module, the GUI prompts a user to save the state of 
the patient's chart. If a user decides not to save the present state of the plan, it returns to its 
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previous state; that is» the state the plan was in before you began charting. Therefore, no 
changes will be reflected the next time it is opened for charting. 
1. Charting Into the Plan Node 
A user may similarly chart into Chart view, as described above. Except when a user 
5 decides to archive the old plan, the order result information is not listed in the Chart view, while 
not archiving will leave the information in the Chart view as part of the patient history data. 
C. Flow Chart and Chart View Loric Flow Diagram 

Fig. 40 illustrates a logic flow diagram for displaying a Flow Chart and View Chan 
according to the present invention. 

10 In logic 800, a determination is made whether a user moves the window splitter up or 

down. If the user BDd is moved the splitter down, a determination is made in logic block 801 
to display a Flow Chart view of a patient plan. Accordingly, in logic 802, a time slot object 
(real time slot 363 as seen in Fig. 27) from the plan object (plan object 360 as seen in Fig. 27) 
is obtained. The screen is updated with a time scale and unit size according to the time slot 

15 object. The node list in the plan searched for the next active node in the plan object obtained in 
logic 803. In logic block 804, if the state attributes of the node object is checked to see if it is 
executed. The node is then colored with a user-selected color if the state of the node is 
executed. A determination is made in logic block 805 whether the node is a destination of a 
previous node. If the node is a destination of a previous node, an arrow is drawn between the 

20 parent node and this node. A determination is then made whether the node is the last node in a 
plan object. If the present node is not the last node, the logic loops back to logic block 803. 
Otherwise a Flow Chart view is drawn. If a user selected the view chart, the logic proceeds to 
logic block 806. A table with predefined numbers of rows and fonts is drawn. The time slot 
object is then obtained from the plan object in logic block 807. The real time of each slot is also 

25 obtained and used as a label for each column. A determination for the most probable path is 
also determined by examining the probability value of each path in logic block 808. Data for the 
next order of the selected node is then obtained in logic block 809. This data is filled in the cells 
of the next available column. The status from the corresponding result node is then obtained in 
logic block 810. The status of the items in the result node in the cells of the next available 
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column are then displayed. The stams of the node is then checked in logic block 81 1 and 
colored accordingly. Finally, a determination is made whether the last node in the view chart 
form is the present node. If a present node is not the last node, the logic loops back to logic 
block 808. Otherwise, the view chart is displayed. 

5 V. CUSTOMIZING A TEMPLATE OR PLAN 

If the patient's treatment isn't covered in a generic template, a user can copy an existing 
template similar to one needed and modify it to suit a specific patient. A user can customize a 
template by adding nodes* deleting nodes, or modifying node contents in a Flow Chart view. 

A. Deleting a Node 

10 Deleting any of the nodes in a triplet removes the entire triplet. Exit nodes may be 

deleted separately and Start nodes may not be deleted. 

B. Modifving the Clinic Template 

Suppose a user has a patient who may have Strep throat but also requests a prescription 
for.a preexisting condition such as migraine headaches. A user needs to modify the Clinic 
IS template to include a prescription for Tylenol m. 
To modify the Clinic template: 

a. Open the Clinic template that was previously assigned to a patient. 

b . Double-click the Str^? node to open the Orders dialog. 

c. Click Add button 117 in the Orders node detail dialog box shown in Fig. 11. 

20 d. Double-click Meds, Pharmacy, and PO_Pain_Meds_TylenoLin ($10.00) in the 

Command list of the Add Orders dialog box 122 shown in Fig. 12. 

e. Click Place Order button 127 and then click Done button 124. 

f . Click OK button 113 in the Orders dialog box 1 10. 

The number above the Strep and Rel nodes change to 3 indicating that there are now 
25 three work orders associated with these nodes. 

The same set of operations to modify the protocol during the plan delivery phase may be 
used in the charting/walk- through module. In an embodiment, the customization can only be 
done in the Flow Chart view and the toolbox is hidden by default in plan delivery mode. 
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VI. EXPORTING PATIENT PLAN DATA 

The GUI, according to the present invention, provides several ways to export data 
gathered during charting. DDE (Dynamic Data Exchange) allows GUI to notify another 
Windows application when orders are placed and rules are active. A patient plan may be 
S exported in a format that can be read by applications such as Microsoft's Excel spreadsheet. 
Fig. 41 illustrates a plan element, exported from the "clinic.pln" and imported into an Excel 
Spreadsheet A modified patient plan can also be exported as a generic template. 
A. Using DDE 

In the Options menu, the commands DDE Enabled/DDE Disabled, allows a user to 
10 export the data in the Result node to other applications that support DDE. 

For example, an Excel spreadsheet can contain macros that will read the DDE data and 
enter them into various cells in the spreadsheet. First, start Excel and open the spreadsheet 
Then start the GUI Chart Patient module and choose DDE Enabled from the Options menu. 
When a user enters data into the results forms, the data is also sent to the Excel spreadsheet 

IS B. AiSCTIRTOPn Formal 

When a plan is exported as an ASCII format file, each element in the plan is written on a 
separate line. Each line may contain several values that describe the plan element These values 
are separated with commas and arranged in columns. This comma-separated value format is 
easily read by most spreadsheet and data base software, and other analysis programs. 

20 c. Using AnalvrePaticnB 

Araxsys^ Solution's Analyze Patients module also allows users to extract data from a 
template and convert it to a standard format that other Windows programs can read 

a. Click the Analyze Patients button 73 from the Main Directory window as shown 
in Fig. 7. A dialog box opens and displays the list of patients a user has entered 

25 (from the Patient Assignment window). 

b. Click the patient name to see a list of the templates integrated into the patient's 
plan. 

c . From the list, select the plan template a user wants to export 
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d. Choose the desired data format and click the Export button. A user will be 

prompted to enter a file name for the converted data file. 

e. To input the data into the other application, open that application and use its 
Import command. This command is usually on the File menu. 

A user can also print the converted data using the **Print*' option on Export dialog box. 
The plan data is printed in a table format 


VII. MERGING HEALTHCARE PLANS 

A. Merging Plans 

When a new patient is enrolled and placed on a treatment protocol, for example, the first 
10 template is assigned to a new patient and the template becomes the patient's master plan. It is 
often the case that the patient will need to be placed on a new, possibly unrelated, treatment 
protocol, such as started on a new template, while the first plan is still in effect, such as a 
pregnant woman on a prenatal plan with a sore throat To handle these cases, a user simply 
assigns a new, additional template to the patient 
15 At this point, the physician has to decide whether to merge the new template with the 

master plan, or start the template as a separate plan in parallel with the master plan. The default 
behavior is to execute the two plans in parallel, but this may be undesirable if the orders in the 
new plan conflict with the orders in the master plan. 

When there is a chance of orders conflicting between plans, a user should merge the 
20 new plan into the master plan. The merge process will allow a user to resolve the conflicts and 
plan out a treatment course that covers both conditions effectively. 

B. The Merge Process 

The merge process begins when a template is assigned to a patient that is currently on an 
active plan. This section explains the merge process using a simple example scenario to 
25 illustrate each step. In the scenario, Mr. Sanders is having his hip replaced according to the 
hip.pln template. Presently, Mr. Sanders is on day four of the hip replacement plan and is 
being treated for a fever that has developed after surgery. On this day, Mr. Sanders manages to 
hurt his wrist on the bed rail while reaching for his book. His doctor assesses the sweUing and 
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decides to place him on wrist trauma protocol designed specifically for patients with an 
intravenous C'lV"), that is, the protocol prescribes IV medications instead of oral.medications. 
Since the wrist trauma protocol will likely impact the hip replacement plan, Mr. Sanders' doctor 
decides to merge the wrist plan with the hip replacement plan. In order to merge the plans, the 
following steps axe completed: 

a. First, assign the wrist trauma template to the Mr. Sanders master plan - the 
hip.pln he has been on for several days. Click the Assign Templates to Patients 
button 71 from the Main Director shown in Fig. 7 to bring up the Plan 
Assignment Window shown in Fig. 42. 

Fig. 42 shows how the Plan Assignment window looks just before die wristpln is 
assigned to Mr. Sanders. The wristpln template and Mr. Sanders are selected. 

b. Click the Assign Template button 900. The wrist urauma plan, wristpln, is now 
listed beneath the hip replacement plan, hip.pln, as shown in Fig. 42a. 

c. Double-click the wristpln line listed beneath Mr. Sanders* name in the patient 
list Doing so brings up the wrist trauma plan. wrist.pln, in the Flow Chart 
view. The first triplet is highlighted to indicate it is the next step in this plan. 

d. Maximize the wrist.pln window and pull down the splitter bar to divide the Flow 
Chart view in half. The splitter bar is the thin, raised gray bar just below the 
Flow Chart view window title bar. This reveals both the wrist tt^uma plan and 
the master plan, namely the hip plan in this example, as shown in Fig. 43. 

When the plan is first opened, it shows both plans starting from the first time slot 
When plans are merged and have different time slot settings, the time slot setting from the plan 
with more narrow focus.shorter duration is selected for the integrated plan. For this reason, it 
may be necessary to adjust placement of nodes in the plan that changed to make sure nodes are 
in the proper time slots. In this example, both plans have time slot settings by day and this 
adjustment is not necessary. 

e. Before a user can merge the wrist plan into the active hip plan, a user needs to 
move the wrist nodes to day four where the hip plan is presently active. Select 
the Order Node in the first uiplet in the wrist plan and choose Select All Nodes 
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Right from the Edit menu. This selects all of the wrist plan nodes. Now. drag 
the nodes to the right until the first triplet is positioned in day four and the 
second set of triplets is positioned in day five. Next, scroll the hip plan to the 
right until both plans are aligned by time slot Adjust the scrolling so that a user 
5 can see all of day four and five. When a user is done, the Flow Chart view 

window looks similar to Fig. 44. 
The nodes in the wrist plan are merged into the hip plan at day four because Mr. 
Sanders is presently on day four of the hip plan when the wrist injury occurs. In this example, 
the merge needs to take place on day four. But in general, selecting a time slot may not be 
10 ^parent because more than one time slot may be active in a plan. 

Nodes in the next plan step become active once a rule is satisfied in the current plan 
step. Rules often only reference one or two order results out of all that may be available in the 
triplet. If one of two orders are filled and show results that trigger a rule, the plan may branch 
to the next step before some of the other orders are completed. When this happens, two steps 
15 becpme active in the plan. The outstanding orders may be filled in the previous step and the 
new orders may be filled in the newly activated step. But, since the plan has moved to a new 
step, the rules in the previous step are no longer checked; they no longer direct the plan flow. 

The right-most active triplet is the leading active triplet and is the site of the next branch 
in plan. Nodes in the second plan may not be merged into time slots before the leading active 
20 node in the master plan. A user cannot merge a node before this triplet in the master plan, 
because the new node would not be able to participate in the branching decisions. 

Since nodes are merged on a time slot by time slot basis, a user needs to reposition the 
nodes to make sure that no more than one plan step is present in each path in the day four and 
five timeslots. A user cannot have two or more triplets in a sequence, or a triplet followed by 
25 an exit node in the same time slot Since the second step in the wrist plan contain triplets in 
multiple paths (the triplets are on separate paths), it is correct to leave these triplets arranged 
vertically in the same time slot as long as they arc in separate branches of the plan. 

f . Now that all of the nodes have been positioned properly, a user is ready to 
merge the first (active) step in the wrist plan with the active step in the hip plan. 
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Select the order node in the wrist plan and choose the merge option from the 
Edit menu. Fig. 45 shows what the two plans look like after merge (and some 
rearrangements done for cosmetic reasons). 
The Assess.Wrist triplet is merged into both paths in the hip plan. Since no triplet is 
5 present in the upper path (the one that would have been taken had Mr. Sanders not developed a 
fever after surgery), the Assess_Wrist triplet is inserted in its entirety (minus rules in the Flow 
Control node). In the second path, the orders from the Assess_Wrist Order node are added to 
the orders in the Fever_Labs Order node. Notice that before the merge the Assess_Wrist node 
contained three orders and the Fever_Labs node contained six orders, but after the merge the 
10 Fever_Labs+Assess_Wrist node only has eight orders. This is because both nodes contained 
the same order for pain medication. Duplicate orders are removed during a merge. 

The rules from the Assess^Wrist triplet are left in a solitary Flow Control node as a 
place holder until the next step in the plan is merged. 

g. Merging the second step is similar to merging the first step. Select either of the 
15 . Order Nodes in the wrist plan and choose the Merge option from the Edit menu. 

After rearranging the nodes a little and opening the hip plan all the way, the 
resulting merge appears as in Fig. 46. 
As in the merge of the first step, orders were combined and duplicates were removed. 
This time, however, the rules from the previous step were merged into the Flow Control nodes 
20 to reflect the branch in the wrist plan between treating a fracture and treating a sprain. 

This simple example illustrates the basic steps required to merge two plans, but this 
simple example does not highlight any conflicts that may arise during a merge. The merge 
removes duplicate orders, but it does not remove similar orders. In the example, the two plans 
prescribed die same pain medication, but in general, that may not be the case. 
25 After the merge, a user needs to review the orders to make sure the combination of 

orders still makes sense. If another pain medication had been prescribed in the wrist plan, the 
result of the merge would contain two orders for similar, but different, pain medications. Since 
the pain medications prescribed for the hip plan are probably well-suited to handle any pain 
from the wrist injury, a user would probably want to remove the second pain prescription that 
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originated from the wrist pain. 

There are several types of conflicts that may appear after a merge that must be 
addressed. Medications may conflict with one another (e.g., two similar, but different pain 
medications are present). Orders may need to be delayed based on the new condition (e.g., it is 
5 impossible to complete the combined set of orders in the designated time slot). New orders 
may need to be added in addition to the sum of the merged orders (e.g., since Mr. Sanders 
injured the wrist that had the IV site, the IV site needs to be moved to the other arm). In 
addition to these conflicts, there are numerous imforeseen conflicts that may occur when orders 
from tmrelated templates are combined. Users can specify the rules to resolve these conflicts 
10 and store the rules in the library. 

The example scenario indicates several of the adjustments that must be made to the two 
plans before they are merged, but there are a few other constraints that must be addressed in the 
general case. A user must properly arrange the nodes in the two views so that they meet with 
following criteria before merging the triplets in a time slot. 
IS ^ First, both plans must have the same time scale setting. They must be both by day or by 
shift or by visit, etc. If the two plans have different time scale settings, change the time scale in 
the plan with the more broad time scale setting. For example; if one plan is set to days and the 
other is set to shifts, a user should change the plan that is set to days to a plan set with shifts. 
When the time scale setting is changed from days to shifts, a user should reposition the nodes 
20 into the desired shifts within the desired day because the nodes do not move when a user 
changes the time scale setting. 

Second, two or more triples may not be in a sequence, or a triplet followed by an exit 
node in the same time slot Since a single plan step can contain triplets in multiple paths, or 
triplets may (and probably will) be arranged vertically in the same time slot as long as they are 
25 in separate branches of the plan. 

Third, new orders may not be merged into previously executed steps in the master pkm. 
Nodes in a second plan may not be merged into time slots before the leading acdve node in the 
master plan. 

Fourth, nodes may not be merged that have already been completed. If a user has been 
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working with the second plan in parallel with the master plan (e.g., the user has not merged 
plans yet) and then a user decides to merge nodes, a user must start merging with the leading 
active node in the second plan. A user cannot merge fully or partiaDy completed nodes (i.e., a 
triplet with a few orders outstanding) to the left of the leading active node in the second plan. 
S After merging the leading active node, a user can then merge nodes in the subsequent time slots, 
but each time slot must be merged in order from left to right 

Error messages aie displayed if the plans do not meet these criteria. A user can fix the 
problem and try again. 

Once a user begins merging nodes, a user can stop at any time. Those nodes left 
10 unmerged will be maintained as parallel paths until they are merged. If die plan advances to one 
of these parallel paths and they remain unmerged, they can be charted in parallel. 

During the merging process, a user will probably need to move nodes around. There 
are several selection options under the Edit menu to help a user select a group of nodes. For 
example, a user can select a node, choose the "Select All Nodes Right" option from the Edit 
IS menu, and drag all of the selected nodes to the right. 

C. Merging Two or More TemolatRS I/)gic Flow 

Figs. 47 nd 48 illustrate the logic of merging two or more templates. A user opens two 
templates to be merged in a Flow Chart view in logic block 950. The user arranges the two 
templates so that they correspond to correct time slots. An example of two templates to be 

20 merged which are aligned in correct time slots is shown in Fig. 48a. 

A merge object is constructed in logic block 951 and illustrated in Fig. 48b. P? and Q? 
represent flow control node rule expressions. For example, P? represents the rule expression 

"If test result is positive " go to target order triplet A, otherwise target order triplet B. 

While Q? may represent the rule expression ''If temperature is high "go to source order 

25 triplet 1 , otherwise go to source order triplet 2. The merge object consists of all combinations of 
Order nodes in the first template and second template. Each item in this merge object contains 
the source triplet order objects 1, 2, the target triplet order objects A, B, and the new resulted 
triplet order objects called Al, A2, Bl and B2. Table 960 illustrates the various combinations 
of obtaining the resulted order triplet objects. A top Flow Chart view of the in progress merge 
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template is drawn using the merge object in logic block 952 and as iUustrated in Fig. 48c. New 
order triplets, including Al, A2, Bl, and B2 are drawn combining the various order triplets. 
For example, a possible positive test result and high temperature would cause flow to be 
directed to new order triplet Al. Branches from these new triplets will also be drawn. The 
5 content of the new triplet order nodes (Al, A2, Bl, B2) will contain all orders belonging to the 
original order nodes (A, B. 1,2), less the duplicated and content conflicting orders. Logic 
block 953 compares order items from order node objects and determines if dupUcates or 
conflicts exist The action or rule taken on duplicate orders can be stored and retrieved from a 
library item. In logic block 955, original triplets A and B are removed from the top Flow Chart 

10 view. Further, result nodes U? and V? are also removed from the lower Flow Chart view. 
However, the flow control node of the bottom plan remains in order to continue execution 
separately or for further merging. Fig. 48e and logic block 956 illustrate the merged template 
according to the present invention. The node objects of the bottom template are not removed 
from the plan node. Information control connections between order triplets Al, A2, Bl, B2 

15 and the lower flow control nodes are added internally (not shown in Fig. 48c) in order to allow 
for separate or parallel execution. 

D. Outcome and Limitations 

Every time a user selects the merge command, command and result nodes in the lower 
plan disappear. The number of items in the master plan node wiU increase by the same number 
20 which used to be in the lower plan. If there are multiple paths in the time slot in the lower plan 
(the merging plan), there will be new nodes created in the master plan to represent the merged 
plan. 

Nodes containing zero items may be created during merge. These "dummy nodes" are 
created to cany internal information that must be preserved after the merge. 
25 Flow control nodes in a time slot are not merged during the merge of this time slot 

They are merged when the next time slot is merged. If a user chooses not to merge the rest of 
the plan, these nodes and the rest of the plan stay intact and the remaining plan is delivered in a 
parallel fashion as if there were two plans active simultaneously. A user can merge a few time 
slots and decide to postpone the rest of the merge by saving the plans using the Save command. 
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There is no specific limit on how many plans a user can merge. However, a user must 
merge them two at a time. The Chart view always records the actions taken in all plans 
assigned to a patient. 

Whenever a user assigns a new plan to a person, the present invention detects if any of 
5 the existing plans have been completed. If a plan has been completed, the GUI asks a user if 
the completed plan should be archived. A user should archive a completed plan unless a user 
wants to refer to the information in the completed plan while charting a new plan. Archived 
plans do not appear in the Chart view but can be viewed separately with the Open command 
from the file menu. 

10 vm. 5;rrvfr nBJEr r<g to y^iTPPORTrwRAPHTr user interface fGUl) 

The graphic user interface according to the present invention is implemented using 
object-oriented structure software design. An example of object oriented structure design is 
described in Object Oriented Design with Applications ', Booch» Grady, Benjamin/Cumraings 
Publishing Company, Inc. (1991), incorporated by reference herein. A GUI server is 

15 implemented using objects and methods defined below. However, it should be understood that 
other software design principles and architectures could be similarly used to carry out the 

present invention. 

1. npneral Server Ohiect Interfaces 
Every GUI server object 300 supports several standard interfaces. Fig. 26 illustrates 
20 the server object interfaces that may be mixed into any or all of the GUI server objects. For 
example, an order node may have a corresponding server object having the illustrated 
interfaces. Fig. 27 illustrates the relationship between various server objects according to the 
present invention. 

a. ftandard ServpT Ohiect Interface 
25 The standard server object interface is supported by every disnibuted object in the GUI 

server. Every object 300 has a Name 301, Atuibute List 302, and Parent attribute 303. In 
addition, every server object contains a Propagate^Change method 304. 

(i) Namfi APribute 
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The Name attribute 301 is unique for the instance of the GUI server object in its context 
(e.g., a node in a plan, an order in a node, etc.). The Name attribute 301 will likely conform to 
the Name type expressed in The Common Object Request Broker: Architecture and 
Specification. Vision 2.0 ("CORBA Standard") incorporated by reference herein. 
5 (ii) Attributes LKlAttribmc 

The Attributes List 301 is a general set of name/value pairs associated with every server 
object instance. These attributes may be "well known" (e.g., expected to be present) or specific 
to the object class. Well known attributes include Category, Department, and Cost. In orders, 
attributes include results, order qualifications (e.g., drug dosage), and start and finish times. 
10 Attributes 302 may be referenced by rule expressions to determine the branch a patient takes 
through their plan. 

(iii) Parent Attribute 

Most GUI server objects are contained within some other object. The change 
notification scheme requires a given object to identify what changed at their level and then 
IS propogate a change notification up to their parent. The Parent attribute 303 keeps track of 
which object is currently the parent of a given object Parentage can change over time. 

(iv) Propogate Change Mgthod 

A change notification scheme according to the present invention uses a chaining 
mechanism to specifically identify what changed in the GUI server data. When the change 
20 information is compiled, it is passed to all client applications that have registered for change 
notices. 

The change information is compiled into a stack object The object that makes a change 
pushes an entry into the stack indicating what changed at their level. The object then invokes 
the Propogate.Change method 304 in the parent (through the Parent attribute 303). The parent 
25 pushes an entry into the stack indicating the change at their level and invokes 
Propogate.Change method 304 in their parent, and so on. At the top level (a GUI Server 
Component object like a plan, template, patient, etc.), the stack is included in the change even 
that is distributed to all the CORBA clients that have registered for change notices. 

When the client receives the change notice, the client pops the change entries off the 
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Stack. Each change entry identifies the change at each level. If the user of the client application 

is not able to access the element that changed, the change notice may be ignored. 

For example, an order result value is updated (set by a client) during plan delivery. The 

Attribute of the result object creates a change stack object and places the first entry identifying 

5 itself as having changed. Attributes need to notify all of the rule expressions that depend on 
them using a notification mechanism provided in the CORB A standard referenced above. Next, 
it invokes the Propogate^Change method in its parent, an Order Instance object 364, as shown 
in Fig. 27. The Order Instance object 364 places an enuy into the change stack identifying 
itself (e.g., its name, etc.) and invokes Propogate.Change in its parent, an Order object 358. 

10 The Order object 358 indicates that it changed and noufies its parent, a Composite Order 357. 
The Composite Order 357 pushes an entry into the stack and propogates the call up to its parent, 
a Result Node 359. The Result Node 359 pushes an enuy into the stack and propogates the call 
up to its parent, a Node object 352. The Node object does the same and propogates the call to 
the Plan object 360 that contains the Node. The Plan object 360 is the top level component. It 

15 provides the stack object with the call to the change event notification service. This service 
distributes the change notice to all GUI clients that have registered for change notices for this 
particular Plan object. 

Continuing the example, the client application receives the change notices and extracts 
the change stack object from the change event. The top entry in the change stack indicates that a 

20 change occurred in a specific patient's plan. If the client is no longer interested in changes to 
that plan, the notice may be ignored. If the client is currently displaying some aspect of the 
plan, it looks further into the change stack to see which node changed. If the client is interested 
in changes to the specific node, it looks within to find the result node 359, the composit order 
357, the order 358 and so on. If it happens that the client is currenUy displaying the attribute 

25 that changed, it will find the new value at the very bottom of the stack. With this method, any 
change in a plan will be reflected on any user who is using the plan in real time. 

b. ?mm9^\^^^^^^^ 

A factory object 305, as shown in Fig. 26, is an object that creates new instances of an 
object. Almost every server object class will have a corresponding Factory object class. 
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Factories are arranged in the name tree to facilitate the creation of instances on different host 
machines, as illustrated in Fig. 28. A Hosts directory 951 and Factories directory 952 is listed 
in the Name Tree Root 950 (among others). The Factories directory 952 contains a Ust of all 
the object factories in the system. The Hosts directory 95 1 contains references to specific host 
5 directories that exist on the hosts they represent (e.g., the Host.l name context object runs on a 
computer host named "Host.!**). Each host directory contains a list of factories for all the 
objects that may be hosted on that machine (i.e., a user can control which hosts are to run 
which objects by including or excluding the object's factory in the host directory). 

An object that wishes to create a new object instance on a specific host will invoke the 

10 Create.New method 308 in the factory corresponding to the desired object and specify the name 
of the host on which the new object will reside. If a host is specified, the factory traverses the 
name tree through the hosts directory 951 to find the factory residing on the desired host and 
forwards the Create_New request to that factory (without specifying a host name). When a 
factory receives a create request without a host name, it creates the object instance on its own 

15 host 

Other factories, in alternate embodiments, may look at the load and capacity of a 
collection of hosts and allocate the new object to the host with the most available storage and 
CPU capacity. 

c. Container Object Interface 
20 All of the GUI server objects that function as containers support the standard container 

interfaces (as seen in Rg. 26) in addition to the standard server object interfaces. The Container 
object 306 interfaces provide client objects with a standard way to add and remove items from 
containers, obtain an item within a container (the Resolve method 309), and list the names of 
the items within the container. In an embodiment, these interfaces will conform to the CORB A 
25 Standard Services 2.0 specification for containers. In an alternate embodiment, the container 
services may be able to use other environments, such as MAC windows. 
2. Librarv 

Every user may have their own library or link to a common library shared by others. 
The library function is implemented to handle a hierarchy of libraries that roughly correspond to 
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the organization's structure (e.g., network, facilities, departments, etc,). 

Fig. 29 illustrates an example library hierarchy according to the present invention. Each 
physician may have their own library. Each library at the bottom of the tree is able to see items 
up through the hierarchy all the way to the top. Library items added at the top level are available 
5 to everyone within the network. Library items placed in the next level down are available to all 
users working in that type of facility (e.g., Nursing Home or Rehabilitation Center). Items 
added at the next level down are available to all users within the specific facility. Library items 
added at the lowest level are only available to the individual user. 

The content within a library at a given level in the hierarchy may also be organized in a 
10 hierarchy by department and category to organize the items stored in the library. This facilitates 
retrieval. 

a. Sv5rtein Library Ohiect Interfaces 
Fig. 30 illustrates the services provided by the library objects and the items contained 
within the library. System Jibrary objects 400 maintain the hierarchy of libraries across the 

15 network. Within a given library exists a collection of items stored in the library. Any client 
application (as in client-server design) interacts directly with the User^Library objects 402. A 
User^Library instance is associated with every user 495 and connects to the Systero.Library 
hierarchy as a leaf node. User^Library objects 402 traverse up the library hierarchy through the 
ancestor chain and build a Uee of library items from the union of all items in the System_Library 

20 object 400. They allow the client applications to set preferences that identify which items are 
displayed (presumably frequently ordered items) and which items are hidden (items a given user 
does not typically use). 

(i) Root rnntftxt Attribute 

The Root^Context attribute 405 holds the object reference to the root container of the 
25 library at this level in the hierarchy. This container holds other containers and the top level 
library items in this library. 

(ii) ppmntLihrarv Attribute 

Parent Library attribute 406 mainuiins the link to the library above this one in the 
hierarchy. 
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(iii) Children Ubrarigs Attribtttg 

Children Library attribute 407 maintains references to the libraries below this on in the 
hierarchy. 

(iv) Register and Unrarister Methods 

S Register and Unregister methods 408 and 409 allow client applications to register and 

imregister for notifications of changes made to the library. When registered, a client application 
will receive notice when items change in the library at this level. 

(v) Find Item Method 

The Find.Item method 410 allows a client application to search through the library to 
10 find all the items that match the specified attributes and search criteria. The method returns a 
container holding the matching library items, or actually references to the items. 

(vi) Create Context and Create Libltem Methods 

The System.Library object 400 serves as an object factory for library context 
(container) and library item objects. Create Context and Create Libltem methods 41 1 or 412 

15 create a new instance of the specified type of object The new instance is not associated with a 
context and is essentially empty. The client application is expected to initialize the object and 
insert it into the appropriate context (by traversing to the desired context and invoking the 
Addjtem method 413 with the reference of the new object). 

b. User Library Qhiect Interfaces 

20 The User.Library object 402 provides an interface to the client components. Its 

principle function is to provide an iterator to client components that allows them to iterate 
through the library items the user has indicated they wish to see. 

(i) User Anribute 

The User attribute 414 provides a link to the User object 405 associated with a specific 
25 GUI user In an embodiment, every User^Library object 402 instance is associated with one 
user. 

(ii) Get Tree Iterator Method 

The Get_Trce_Iterator method 415 returns an iterator object that is able to traverse 
dirough the tree of library items. The library tree iterator object is able to return references to 
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library items the user has not hidden (using the Hide^Ilem method 416). The library tree 
iterator is able to keep abreast of library changes (in near real-time) and returns only current 
references to client components (e.g., a client invokes the Get.TreeJterator method 415 and 
begins traversing the tree, then another user adds a library item somewhere in the hierarchy; the 
5 iterator vwll return the reference to the new item if it traverses the area in the tree where the new 
item was just added). 

ninHirii. Ttem Method 
The Hidejiem method 416 allows a user to remove an item from the tree that the library 
iterator traverses through. Once hidden, the library iterator will not return the reference to the 
10 item. The item may be brought back using the Showjtem method 417. 

(iv) ^how Item Method 
The Showjtem method 417 searches through the library hierarchy for the specified 
item and, if it finds one, includes it in the tree of items the library iterator traverses through. 

c. T .ihTnntext Ohiect Interfaces 

15 . The LibContext object 403 inherits interfaces from the general Container object. It may 
contain other LibContext objects or libltem objects. 

d. l ihTtem Ohiect Interfaces 

The Libltem object 404 specifies interfaces that all library objects must support (e.g.. 
inherit from). 

20 e. TJhrarv Item Objects 

Each type of library object, as shown in Figs. 27 and 30, possess interfaces specific to 
the object class. These interfaces are discussed in detail below. 
3. Temnlate. Plan and Patients 
This section describes the interfaces for the GUI server objects. Fig. 27 illustrates the 
25 relationships between the GUI server objects. 

a. Template Ohiect Interfaces 
Template objects 350 are stored in either the system or user library. They contain 
Virtual Time Slot objects 351 that, in turn, contain Node objects 352 and Template objects 350. 
A template object 350 can also be embedded within another template (i.e., as a sub-plan). 
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Template objects 350 have a name and attributes like all GUI server objects. They also support 

the Container and Archive interfaces. 

(i) Start N9deAtHit>titg 

Stait.Node attribute 370 allows clients to obtain the first node in the template, the start 
S node. From this node, the climt can traverse through aU of the nodes in the plan. 

(ii) net Node List Attribute 

A client may get a list of object references to all the nodes in a template by invoking the 
Get.Node.List atuibute 371. This attribute returns a list of object references. 

(iiilfiet Time Slot List Attribute 
10 A client may get a list of the virtual time slot objects in the template by invoking the 

Getjnme_Slot_List Attribute 372. This attribute returns a list of object references. 

(iv) Lock and Unlock Methods 

Clients that wish to make changes to a template will need to obtain a lock on a template 
instance. The Lock method 373 allows clients to obtain a lock or indicates the template is 

15 currently locked by another client Clients must obtain a lock before making changes to a 
template. Once the changes are complete, they must call the Unlock method 374 to free the 
template instance so that other clients may make changes. Clients that only need to view a 
template (without making changes) need not obtain a lock on the template, but they should 
register to receive change notifications so they can show users updates to the template when 

20 changes are made by others. 

(v) Register and Unrepister Methods 

Clients that wish to be notified when changes occur in templates must register with the 
template object instance by using register method 375. When they no longer wish to receive 
change notifications, they should uiuegister by using unregister 376. 
25 b. Plan Object Interfaces 

Plan objects 360 represent the patient's integrated plan. There is one instance of a Plan 
object for every patient. These objects contain all the orders from assigned templates. A Plan 
contains a network of Node objects 352 for Orders that have not yet been scheduled. 
Scheduled orders are moved into the Real Time Slot object 363 corresponding to the scheduled 
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Start time of the Order. 

C. pflfipnr Ohiect Interfaces 
Patient objects 361 represent patients in the GUI system. There is one instance of a 
Patient object for each patient. The Patient object maintains connections to the patient's plan 
5 object 360, history object 367 and other items (e.g.. medications, conditions and alerts). 

d. History Object Interfaces 

History objects 362 maintain the order history for the patients in the GUI system. There 
is one instance of a History object for each patient. The History object 362 maintains 
connections to the object archives for all of the orders that have been completed for the patient 
10 It also maintains indices to facilitate fast searches based on templates and orders, and time 
period. 

e. Virtual Time Slot Object Interfaces 

Template objects 350 contain a list of Virtual Time Slot instances for each time slot in 
the template. Virtual Time Slot objects 351 maintain the state of individual time slots in a 
IS template. 

f. Real Time Slot Ohiect Interfaces 

The Real Time Slot Objects 363 represent actual time intervals. They are contained 
within Plan objects to hold orders scheduled to start within a specific time interval. Real time 
slot objects 363 indicate their start time and duration. When orders are scheduled, they are 
20 moved from nodes into Real Time Slot Objects. The Scheduling and tasks management client 
software uses the time slots to display tasks scheduled for individual users. 

g. Resnlt Node Ohiect Interfaces 

The Result Node objects 359 represent the list of result nodes that can proceed from a 
Node object 352. Result Node objects 359 maintain information on the result node and the 
25 decision nodes to allow the clients to reconstruct a full node triplet by combining the 
information from the Node object 352 and the Result Node objects 359. 

h. Cnmposite Or der Ohiect Interfaces 

Composite orders 357 are containers for multiple orders that are grouped together. 

i. Order Object Interfaces 
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The Order object 358 fully describes generalized orders in the GUI system. The Order 
Instance object 364 maintains the data that qualify the order, the order's life cycle, and the 
results gathered when die order is filled. Each order contains at least one order instance object 
j. Ordftr Instance Ohiect Interfaces 
S Order Instance objects 364 capture the state of an instance of an order. Ongoing orders 

will have multiple order instances. Each order instance has attributes that qualify the order, 
hold result values, and mark start and end tiroes. Order Instance objects 364 also have a life 
cycle object within that maintains the current state of the order and acts on events that transition 
the order to its various states. 
10 k. IfRwlcQbjcgtlntgrfaggs 

If Rule Objects 353 contains three elements: a Probability Attribute 377, Destination 
attribute 378, and an Expression Object 354. The Probability attribute maintains the probability 
that the branch associated with this rule is taken (on average). The Destination attribute 
indicates the nodes that will be activated when the rule fires. 
15 . 1. Expression Ohiect Interfaces 

Expression Objects 354 maintain logical expressions. They not only contain the string 
representation of the expression, but the references to all the attributes they depend upon. They 
monitor the life cycle of the orders they depend upon and when the life cycle changes state, they 
check to see if they can now evaluate the expression. 
20 m. Life Cvcle Ohiect Interfaces 

life cycle objects 356 maintain state tables for attributes, orders, templates, plans, etc. 
The state tables have a state and accept events that advance the life cycle to a new state. It may 
support the activation of methods when state transitions occur. 

n. Attribttte Qhiect Interfaces 

25 Attribute objects 355 hold all the data in plans, templates, orders, patients, etc. available 

to GUI for decision making purposes. 
DC. CONCLUSION 

The foregoing description of the preferred embodiments of the present invention has 
been provided for the purposes of illustration and description. It is not intended to be 
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exhaustive or to limit the invention to the precise forms disclosed. Obviously, many 
modifications and variations will be apparent to practitioners skilled in the art. The 
embodiments were chosen and described in order to best explain the principles of the invention 
and its practical applications, thereby enabling others skilled in the art to understand the 
invention for various embodiments and with the various modiHcations as are suited to the 
particular use contemplated. It is intended that the scope of the invention be defined by the 
following claims and their equivalents. 


52 

snsnnnESBsron^W 


wo 97/15021 


Claims 


PCT/US96/16833 


1 ) A data processing apparatus* comprising: 
a display for displaying data; 

input means for supplying input data; 
S a storage location, coupled with the display and the input means, for storing 

data, images, and programs; and 

processing means, coupled to the display means, the input means, and the 
storage means, for controlling the storage means, the input means, and the display means in 
response to stored programs and input data to perform data processing operations; 
10 wherein the display includes, 

a plurality of graphic icon images, stored in the storage location, arranged on the 
display representing a medical treatment plan; 

wherein the stored programs includes, 

a program for merging a first set of graphic icon images representing a first 
IS treatment plan with a second set of graphic icon images representing a second treatment plan to 
obtain a combined treatment plan. 

2) The apparatus of claim 1, wherein the first set of graphic icon images are 
arranged in a chronological sequence and a first icon image in the first set of graphic icon 
images represents a medical order. 

20 3) The apparatus of claim 1, wherein the first set of graphic icon images are 

assigned to a patient. 

4) The apparatus of claim 1, wherein the first set of graphic icon images and the 
second set of graphic icon images are arranged in a first flow chart view and a second chart 
view, respectively. 

25 S) The 24)paratus of claim 1 , wherein the first.set of graphic icon images includes at 

least one order triplet, the order triplet having an order node, result node and flow control node. 

6) The q)paratus of claim 1, wherein the fu^i set of graphic icon images includes at 
least a furst icon image having a first medical order description responsive to input data and the 
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second set of graphic icon images includes ai least a second icon image having a second medical 
order description responsive to input data, and the combined treatment plan includes a third icon 
image representing the first and second medical order description. 

7) The apparatus of claim 6, wherein the stored program eliminates duplicate order 
5 descriptions in the first medical order and the second medical order. 

8) The apparatus of claim 2, wherein the stored program deletes the first order icon 

image. 

9) The apparatus of claim 2, wherein the stored program adds a second order icon 

image. 

10 10) The apparatus of claim 1 . wherein the input means includes a mouse. 

1 1) The apparatus of claim 1, wherein the process means includes a processor. 

12) A method for displaying a graphic representation of a medical treatment plan, 

comprising the steps of: 

providing a first set of icon images representing a first medical u-eatment; 
15 ^ providing a second set of icon images representing a second medical treatment; 

and 

combining the first set of icon images with the second set of icon images to 
obtain a third set of icon images representing a medical treatment including the first and second 
medical treatment 

20 13) The method of claim 12, wherein the method further includes the step of 

arranging the first set of icon images in corresponding time slots with the second set of icon 
images. 

14) The method of claim 12, wherein the method step of providing a first set of icon 
images includes the step of providing an order triplet. 
25 15) The method of claim 14, wherein the order uiplei includes an order node, result 

node and flow control node. 

16) The method of claim 12, wherein the method step of providing a first set of icon 
images includes the step of providing a first order icon image having a corresponding order 
description and the method step of providing a second set of icon images includes the step of 
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providing a second order icon image having a corresponding order description. 

17) The method of claim 16, wherein the combining step further includes the step of 
comparing the first order description to the second order description. 

18) The method of claim 17, wherein the combining step further includes the step of 
S removing a duplicate order description in the first order description and the second order 

description. 

19) The method of claim 17, wherein the combining step further includes the step of 
detecting conflicting order descriptions in the first order description and the second order 
description. 

10 20) The method of claim 1 8, wherein the duplicate order is removed in response to a 

user supplied nile. 

21) The method of claim 12, wherein the step of providing a first set of icon images 
includes the step of providing the first set of icon images in a flow chart and the step of 
providing a second set of icon images includes the step of providing the second set of icon 

IS images in a flow chart 

22) The method of claim 12, wherein the method further includes the step of 
assigning the first set of icon images to a patient. 

23) An article of manufacture including a computer readable medium having 
computer readable program code means embodied therein for displaying a medical treatment 

20 plan, the computer readable program code means in the article of manufacture comprising: 

computer readable program code means for causing a computer to generate an 
image on a display representing a first medical treatment; 

computer readable program code means for causing a computer to generate an 
image on a display representing a second medical treaunent; and 
25 computer readable program code means for causing a computer to combine the 

image representing the first medical treatment with the image representing the second medical 
treatment to display a combined medical treatment image. 

24) The article of manufacture of claim 23, wherein the image representing the first 
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medical tieatroent includes an order icon image having a corresponding order description. 

25) The article of manufacture of claim 24, wherein the image representing the 
second medical treatment includes an order icon image having a corresponding order 
description. 

5 26) The article of manufacture of claim 24, wherein the order icon image is an order 

triplet including an order node, a result node and a flow control node. 

27) The article of manufacture of claim 23, wherein the article of manufacture further 
includes a computer readable program code means for causing a computer to generate a chart 
view of the image representing the first medical treatment and the image representing the second 

10 medical treatment 

28) The article of manufacture of claim 23. wherein the article of manufacture further 
includes: computer readable program code means for causing a computer to generate the image 
of the first medical treatment in time slots on a display conresponding to the image of the second 
medical treatment 

15 29) The article of manufacture of claim 23, wherein the article of manufacmre further 

includes a computer readable means for causing a computer to assign the image representing the 
first medical treatment to a patient 

30) The article of manufacture of claim 25, wherein the article of manufacture further 
includes computer readable means for causing a computer to compare Uie first order icon image 

20 description to the second order icon image description. 

3 1) The article of manufacture of claim 25, wherein the article of manufacture further 
includes computer readable means for removing duplicate order descriptions in die combined 
medical treatment 

32) The article of manufacture of claim 26, wherein the article of manufacture further 
25 includes computer readable means for causing a computer to assign a result value to the result 

node image. 
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Plan Node Detail 
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USER DECIDE THE TIME SLOT SCHEME. 



TIME SCALE DIALOGUE BOX IS DISPLAYED. 
USER SELECT THE SCALE AND UNIT 



TEMPLATE OBJECT IS 
THE NEW TIME SCALE 

UPDATED TO REFLECT 
AND TIME SLOT SIZE. 


-500 


■501 


-502 


-503 


DETERMINE THE NUMBER OF TIME SLOTS IN TEMPLATE BUILDER 
WINDOW AND LABEL THE WINDOW REFLECTS THE NEW SELECTION. 


USER SELECTS THE NODE ICON IN THE TOOLBOX 
AND DROPS THE ICON NEXT TO THE START NODE. 


-504 


505 


DRAW THE RECTANGLE FOR THE TRIPLET (ORDER RESULT 
AND FLOW CONTROL NODE) AND LINK ICON IMAGE. 


-506 


.CREATE A NODE OBJECT, ADD IT TO THE NODE-LIST OF THE TEMPLATE 
OBJECT; CREATE THE ASSOCIATED ATTRIBUTES OF THE NODE. 
DETERMINE A UNIQUE NAME FOR EACH NODE OF THE TRIPLETS. 


IS 

THIS THE 
LAST NODE BEFORE 
EXIT NODE 

7 

Tyes 


USE THE CONNECT TOOL TO CONNECT ALL THE 
NODES CREATED IN THE TEMPLATE BUILDER WINDOW. 


-507 


CLICK A SELECTED NODE TO FILL ITS CONTENT: 

AN ORDER NODE WINDOW IS DISPLAYED '08 

WITH ORDER CONTENT FROM THE 
NODE OBJECT (EMPTY FOR NEW NODE). 


CLICK ADD TO ADD CONTENT: LIBRARY ORDER ^ sqq 
ITEMS OBJECT IS TRAVERSED TO LIST ALL ORDERS ^ 
IN THE LIBRARY IN THE ORDER DIALOG BOX. 
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CLICK THE ORDER ITEMS IN THE ORDER WHICH WILL 
ADD THE ITEM TO THE NODE OBJECT. ATTRIBUTES 
OF THE ORDER ARE ADDED 


NAME OF THE NODE CAN BE CHANGED USING THE 
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OR CLICK THE EDIT RULE 
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OF THE TEMPLATE OBJECT 


600 


SEARCH FOR THE NEXT DESTINATION NODE 
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DID THE USER MOVE THE WIN- 
DOW SPLITTER UP OR DOWN. 


«°°VIEW 
CHART 


DOWN 


801 


NEED TO DISPLAY THE FLOW 
CHART VIEW OF THE PLAN. 


802 


GET THE TIME SLOT OBJECT 
FROM THE PLAN OBJECT; UP- 
DATE THE SCREEN WITH TIME 
SCALE AND UNIT SIZE ACCOR- 
DING TOTHETIME SLOT OBJECT. 


-803 


GET THE NEXT NODE IN THE 
PLAN OBJECT AND DRAW THE 
RECTANGLES FOR THE ICONS 
AND LINK IMAGES FOR THE ICONS 
WITH THE PERCENTAGE (IF THE 
PERCENTAGE OPTION OF THE 
TEMPLATE OBJECT IS SET) RE- 
CORDED IN THE NODE OBJECT 


804 


CHECK IF THE STATE OF THE 
NODE. IF STATE = EXECUTED. 
COLOR THE NODE WITH A 
USER SELECTED COLOR. 


805 


CHECK IF THIS NODE IS 
DESTINATION OF A PREVIOUS 

NODE. IF YES. DRAW AN 
ARROW BETWEEN THE PARENT 
NODE AND THIS NODE. 


NO 


IS 

THIS THE 
LAST NODE OF THE 
^PLAN OBJECT^ 

? 

Tyes 


(done) 


-806 


CREATE A TABLE WITH PRE- 
DEFINED NUMBER OF ROWS. 
FONTS. COLOR AND CELL 
SIZE. ETC. 


807 


GET THE TIME SLOT OBJECT 
FROM THE PLAN OBJECT AND 
COMPLETE THE REAL-TIME OF 
EACH SLOT AND USE IT AS THE 

LABEL OF EACH COLUMN. DE- 
TERMINE THE MOST PROBABLE 
PATH USING THE ASSIGNED 
PERCENTAGE. 


808 


SELECT THE ORDER NODE OF 
THE MOST PROBABLE PATH. 


-809 


GET DATA FROM THE NEXT 
ORDER ITEM OF THE SELECTED 
NODE. FILL DATA INTO THE 
CELLS OF THE NEXT 
AVAILABLE COLUMN. 


810 


GET STATUS FROM THE COR- 
RESPONDING RESULT NODE. 
PUT THE STATUS OF THE ITEM 
IN THE RESULT NODE IN THE 
CELLS OF THE NEXT 
AVAILABLE COLUMN. 


-811 


CHECK THE STATUS OF THE 
NODE. IF STATUS = EXECUTED 
THE CELL COLOR CHANGES 
TO GREY IF STATUS = ACTIVE 
COLOR IS SEXTO WHITE. 



(done) 


FIG. 40 
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Plan Assignment 


Existing Patients 


& P atients 


& I John Sanders 

hip.pln 
CD Jim Harding 


New Patient Name 
SS# 


Available Templates 


3exit.pln 

Arthrit.pln 

bp.pln 

clinic.pin 

hip.pin 

infect.pln 

lab.pln 

mydinic.pln 

nwclinic.pin 

planl.pin 

plan46.pln 

screen.pin 

seq.pin 

shotgun.pin 

terTiplate.pln 


n 


-900 


Add New Patient | [Assign Template 1 1 Delete 1 1 Done 


Help 


FIG. 42 


Plan Assignment 


Existing Patients 


& ! 

^ & John Sanders 
[-□ hip.pin 
wrist.pln 


Available Templates 


3exit.pln 

clinicpln 

clinid.pln 

clinicr.pln 

hip.pin 

infect.pln 

planl.pin 

polyp.pin 

screen.pin 

S6q.pln 

shotgun.pln 

trauma.pln 

wristpln 


New Patient Name| 

SS# I ■ - 


Add New Patient [[Assign Template 1 1 Delete II Done || Help 


FIG. 42A 
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USER OPENED BOTH TEMPUTES IN FLOW-CHART 
VIEW AND ALL STEPS TO BE MERGED ARE IN THE 
CORRECT TIME SLOTS. SEE FIG 48A. USER 
CLICKS MERGE 


A MERGE OBJECT CONSISTS OF ALL COMBINATIONS 
OF THE ORDER NODES IN THE FIRSTTEMPLATE AND 
THE ORDER NODES IN THE SECOND TEMPLATE (SEE 
FIG. 488) ARE CREATED. EACH ITEM IN THIS OBJECT 
CONTAINS THE SOURCE OBJECT, TARGET OBJECT 
AND THE NEW RESULTED OBJECT 


ACCORDING TO THE MERGE OBJECT. THE TOP FLOW- 
CHART VIEW. WHICH IS THE VIEW FOR THE MERGED 
TEMPLATE WILL BE REDRAWN. THE NEW TRIPLETS 
BASED ON THE MERGED ORDERS WILL BE DRAWN. 
BRANCHES (ARROW) FROM THE NEWLY CREATED F.C. 
NODE TO THE DESTINATION WILL ALSO BE DRAWN. 
THE CONTENT OF THE NEW ORDER NODES WILL 
CONTAIN ALL ORDERS BELONGING TO THE ORIGINAL 
ORDER NODE. LESS THE DUPLICATED AND 
CONFLICTING ORDERS. 


BASED ON THE ORIGINAL RC. NODES OF THE 
PREVIOUS TIME SLOT AND THE NEW DESTINATION 
NODE. THE LOGICS IN THE RULES OF THE PREVIOUS 

TIME SLOTS RC. NODE ARE COMBINED AND 
ENTERED INTO THE F.C. NODE IN THE PREVIOUS TIME 
SLOT OF THE MERGED TEMPLATE (SEE FIG. 48D.) 


NEW ARROWS FROM THE UPDATED FLOW CONTROL 
NODE IN THE PRESENT TIME SLOT AND THE NEWLY 
CREATED MERGED TRIPLETS ARE DRAWN. 


THE ORIGINAL TRIPLETS FROM THE TOP PLANS. THE 

ORDER NODES AND THE RESULT NODES ARE RE- 
MOVED FROM THE BOTTOM PLAN. BUT THE RC. NODE 
OF THE BOTTOM PLAN ARE NOT REMOVED FOR THE 
NEXT MERGE OR TO CONT INUE EXECUTION SEPARATELY 


THE NODE OBJECTS OF THE BOTTOM TEMPLATE ARE 
NOT REMOVED FROM THE PLAN NODE. INFORMATION 
FLOWS FROM THE NEWLY CREATED OBJECTS ARE 
ADDED TO THESE OBJECTS ON THE BOTTOM PLAN 
SO IT CAN BE EXECUTED SEPARATELY IF USER DOES 
NOT WANT TO CONTINUE THE MERGING FOR THE 
NEXT TIME SLOT 


[ DONE ) 

FIG. 47 
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FIG. 48D 
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